Skip to content

HTTPS clone URL

Subversion checkout URL

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