docs/glossary.pod

   1 # Copyright (C) 2001-2008, Parrot Foundation.
   2 # $Id$
   3
   4 =head1 NAME
   5
   6 docs/glossary.pod - Parrot Glossary
   7
   8 =head1 SUMMARY
   9
  10 Short descriptions of words and acronyms found in Parrot development.
  11
  12 =head1 GLOSSARY
  13
  14 =for comment
  15 Please keep this file alphabetical.
  16
  17 =over 4
  18
  19 =item AST
  20
  21 Abstract Syntax Tree: a data structure typically generated by a language
  22 parser.
  23
  24 =item bcg
  25
  26 Byte Code Generation: bcg will be part of the Parrot Compiler
  27 tools. It will aid in converting POST to byte code.
  28
  29 =item Continuations
  30
  31 Think of continuations as an execution "context". This context includes
  32 everything local to that execution path, not just the stack. It is a snapshot
  33 in time (minus global variables). While it is similar to C's C<setjmp> (taking
  34 the continuation)/C<longjmp> (invoking the continuation), C<longjmp>'ing only
  35 works "down" the stack; jumping "up" the stack (ie, back to a frame that has
  36 returned) is bad. Continuations can work either way.
  37
  38 We can do two important things with continuations:
  39
  40 =over 4
  41
  42 =item 1
  43
  44 Create and pass a continuation object to a subroutine, which may recursively
  45 pass that object up the call chain until, at some point, the continuation can
  46 be called/executed to handle the final computation or return value. This is
  47 pretty much tail recursion.
  48
  49 =item 2
  50
  51 Continuations can be taken at an arbitrary call depth, freezing the call chain
  52 (context) at that point in time. If we save that continuation object into a
  53 variable, we can later reinstate the complete context by its "handle". This
  54 allows neat things like backtracking that aren't easily done in conventional
  55 stacked languages, such as C. Since continuations represent "branches" in
  56 context, it requires an environment that uses some combination of heap-based
  57 stacks, stack trees and/or stack copying.
  58
  59 =back
  60
  61 It is common in a system that supports continuations to implement
  62 L<co-routines|"Co-Routines"> on top of them.
  63
  64 A continuation is a sort of super-closure. When you take a continuation, it
  65 makes a note of the current call stack and lexical scratchpads, along with the
  66 current location in the code. When you invoke a continuation, the system drops
  67 what it's doing, puts the call stack and scratchpads back, and jumps to the
  68 execution point you were at when the continuation was taken. It is, in effect,
  69 like you never left that point in your code.
  70
  71 Note that, like with closures, it only puts the B<scratchpads> back in scope -
  72 it doesn't do anything with the values in the variables that are in those
  73 scratchpads.
  74
  75 =item Co-Routines
  76
  77 Co-routines are virtually identical to normal subroutines, except while
  78 subroutines always execute from their starting instruction to where they
  79 return, co-routines may suspend themselves (or be suspended asynchronously if
  80 the language permits) and resume at that point later. We can implement things
  81 like "factories" with co-routines. If the co-routine never returns, every time
  82 we call it, we "resume" the routine.
  83
  84 A co-routine is a subroutine that can stop in the middle, and start back up
  85 later at the point you stopped. For example:
  86
  87     sub sample : coroutine {
  88        print "A\n";
  89        yield;
  90        print "B\n";
  91        return;
  92     }
  93
  94     sample();
  95     print "Foo!\n";
  96     sample();
  97
  98 will print
  99
 100      A
 101      Foo!
 102      B
 103
 104 Basically, the C<yield> keyword says, "Stop here, but the next time we're
 105 called, pick up at the next statement." If you return from a co-routine, the
 106 next invocation starts back at the beginning.  Co-routines remember all their
 107 state, local variables, and suchlike things.
 108
 109 =item COW
 110
 111 Copy On Write: a technique that copies strings lazily.
 112
 113 If you have a string A, and make a copy of it to get string B, the two strings
 114 should be identical, at least to start. With COW, they are, because string A
 115 and string B aren't actually two separate strings - they're the same string,
 116 marked COW. If either string A or string B are changed, the system notes it and
 117 only at that point does it make a copy of the string data and change it.
 118
 119 If the program never actually changes the string - something that's fairly
 120 common - the program need never make a copy, saving both memory and time.
 121
 122 =item destruction
 123
 124 Destruction is low level memory clean up, such as calling C<free> on
 125 C<malloc>ed memory.  This happens after L<"finalization">, and if resources are
 126 adequate, may only happen as a side effect of program exit.
 127
 128 =item DOD
 129
 130 Dead Object Detection: the process of sweeping through all the objects,
 131 variables, and whatnot inside of Parrot, and deciding which ones are in use and
 132 which ones aren't. The ones that aren't in use are then freed up for later
 133 reuse. (After they're destroyed, if active destruction is warranted.)
 134
 135 See also: L<"GC">
 136
 137 =item finalization
 138
 139 Finalization is high-level, user visible cleanup of objects, such as closing an
 140 associated DB handle. Finalization reduces active objects down to passive
 141 blocks of memory, but does not actually reclaim that memory. Memory is
 142 reclaimed by the related L<"destruction"> operation, as and when necessary.
 143
 144 =item GC
 145
 146 Garbage Collection: the process of sweeping through all the active objects,
 147 variables, and structures, marking the memory they're using as in use, and all
 148 other memory is freed up for later reuse.
 149
 150 Garbage Collection and Dead Object Detection are separate in Parrot, since we
 151 generally chew through memory segments faster than we chew through objects.
 152 (This is a characteristic peculiar to Perl and other languages that do string
 153 processing. Other languages chew through objects faster than memory)
 154
 155 See also: L<"DOD">
 156
 157 =item HLL
 158
 159 High-Level Language; Any of the languages that target the parrot virtual
 160 machine.
 161
 162 =item ICU
 163
 164 International Components for Unicode
 165
 166 ICU is a C and C++ library that provides support for Unicode on a variety of
 167 platforms. It was distributed with parrot at one time, but current releases
 168 require you to get your own copy.
 169
 170 L<http://oss.software.ibm.com/icu/index.html>
 171
 172 =item IMCC
 173
 174 Intermediate Code Compiler: the component of parrot that compiles PASM
 175 and PIR into bytecode.
 176
 177 See also L<"PIR">.
 178
 179 =item JAPH
 180
 181 Just another Parrot Hacker: or, a small script that generates that text.
 182
 183 =item MRO
 184
 185 Method resolution order
 186
 187 =item NCI
 188
 189 Native Call Interface: parrot's interface to native "C" libraries,
 190 without a C-compiler.
 191
 192 =item NQP
 193
 194 Not Quite Perl (6):  designed to be a very small compiler for
 195 quickly generating PIR routines to create transformers for Parrot (especially
 196 HLL compilers).
 197
 198 See also L<"PCT">.
 199
 200 =item Packfile
 201
 202 Another name for a PBC file, due to the names used for data structures in one
 203 of the early implementations in Perl 5.
 204
 205 =item PAST
 206
 207 Acronym for Parrot Abstract Syntax Tree, a set of classes that represent an
 208 abstract syntax tree.
 209
 210 See also L<"PCT">.
 211
 212 =item PBC
 213
 214 Parrot Byte Code. The name for the "executable" files that can be passed to the
 215 Parrot interpreter for immediate execution (although PASM and IMC files can be
 216 executed directly, too).
 217
 218 See also L<"Packfile">.
 219
 220 =item PCT
 221
 222 Parrot Compiler Toolkit: a complete set of tools and libraries
 223 that are designed to create compilers targeting Parrot. The principal
 224 components of PCT are PGE, PCT::HLLCompiler (a compiler driver), PAST classes,
 225 POST classes, PCT::Grammar (a base class for PGE grammars).
 226
 227 In the ideal case, a language can be implemented by providing its parser
 228 (using Perl 6 rules) which is generated by PGE, and providing a module written
 229 in NQP that contains the I<actions> that are to be invoked during the parse.
 230 These actions can then create the appropriate PAST nodes. A PAST to PIR
 231 transformation already exists. Depending on the language, other phases can
 232 be added, or overridden (for instance, the PAST to PIR transformation).
 233
 234 =item PIRC
 235
 236 Acronym for PIR Compiler, a PIR compiler currently under development.
 237 The purpose is to reimplement the PIR language, which is currently
 238 implemented by IMCC. PIRC is written using a Bison and Flex grammar
 239 specification.
 240
 241 =item PDD
 242
 243 Parrot Design Document: documents that describe the features parrot must
 244 implement.
 245
 246 See also L<pdds/pdd00_pdd>.
 247
 248 =item PGE
 249
 250 Parrot Grammar Engine.
 251
 252 See also L<"PCT">.
 253
 254 =item PIL
 255
 256 Pugs' Intermediate Language.
 257
 258 =item PIR
 259
 260 Parrot Intermediate Representation: A medium-level assembly language for Parrot
 261 that hides messy details like register allocation so language compiler writers
 262 who target Parrot don't have to roll their own. Files have the
 263 extension C<.pir>.
 264
 265 =item PMC
 266
 267 Polymorphic Container:  these classes are the primitives that
 268 HLLs use to represent their fundamental types, such as Perl's
 269 scalar values.
 270
 271 =item Pod
 272
 273 The preferred format for all kinds of documentation in Parrot.
 274
 275 =item POST
 276
 277 Parrot Opcode Syntax Tree: A set of classes that represent opcodes.
 278
 279 See also L<"PCT">.
 280
 281 =item Predereferencing
 282
 283 =for comment
 284 XXX This section needs to be edited down.
 285
 286 A bytecode transformation technique which reduces the amount of pointer
 287 dereferencing done in the inner loop of the interpreter by pre-converting
 288 opcode numbers into pointers to their opfuncs, and also converting the register
 289 numbers and constant numbers in the arguments to the ops into pointers.
 290
 291 The original implementation by Gregor Purdy was posted on 2001-12-11.  On one
 292 test system, it resulted in a 22% speed increase on a test program with a tight
 293 inner loop.
 294
 295 L<http://archive.develooper.com/perl6-internals@perl.org/msg06941.html>
 296
 297 On 2001-12-18, predereferencing got a speed boost (to about 47% faster than the
 298 regular DO_OP inner loop -- without compiler optimizations turned on). This was
 299 due to an off-list (actually over lunch) suggestion by John Kennedy that
 300 instead of pre-initializing the new copy of the bytecode with NULL pointers, we
 301 pre-initialize it with pointers to a pseudo-opfunc that does the
 302 predereferencing whenever it is encountered.
 303
 304 On 2002-04-11, Jason Gloudon suggested combining aspects of the Computed Goto
 305 Core and the Prederef[erencing] Core.
 306
 307 L<http://archive.develooper.com/perl6-internals@perl.org/msg07064.html>
 308
 309 The week of 2003-02-09, Leopold Toetsch combined Computed Goto and
 310 Predereferencing to produce the CGP core.
 311
 312 L<http://dev.perl.org/perl6/list-summaries/2003/p6summary.2003-02-09.html#Week_of_the_alternative_runloops>
 313
 314 Later, on 2003-02-14, Leopold Totsch and Nicholas Clark combined the JIT and
 315 the Computed Goto Prederef cores to great effect.
 316
 317 L<http://www.perl.com/pub/a/2003/02/p6pdigest/20030216.html>
 318
 319 =item run core
 320
 321 aka run loop, aka runcore. The way Parrot executes PBCs.
 322 See L<running.pod> for a list of available runcores, and how to tell
 323 parrot which one to use.
 324
 325 =item SMOP
 326
 327 Simple Meta Object Protocol: A prototype object model written in PIR.
 328
 329 =item TGE
 330
 331 Tree Grammar Engine: a tool that can be used to generate tree transformers.
 332
 333 =item vtable
 334
 335 A table of operations attached to some data types, such as PMCs and strings.
 336 Vtables are used to avoid using switches or long C<if> chains to handle
 337 different data types.  They're similar to method calls, except that their names
 338 are pre-selected, and there is no direct way to invoke them from PIR.
 339
 340 =item Warnock's Dilemma
 341
 342 The dilemma you face when posting a message to a public forum about something
 343 and not even getting an acknowledgment of its existence. This leaves you
 344 wondering if your problem is unimportant or previously addressed, if everyone's
 345 waiting on someone else to answer you,  or if maybe your mail never actually
 346 made it to anyone else in the forum.
 347
 348 =back
 349
 350 =cut