[svn:parrot-pdd] r11894 - trunk/docs/pdds
Author: chip Date: Mon Mar 13 15:41:32 2006 New Revision: 11894 Modified: trunk/docs/pdds/pdd03_calling_conventions.pod Log: Undeprecate the MAYBE_FLAT bit, which (contrary to my mistaken memory) is not unused, but is in fact very often used for Perl 6. New features: (1) When a hash value is flatted for MAYBE_FLAT, it must be flattened as a list of pair PMCs; and (2) the proper pair PMC class to use for this purpose must be indexed by HLL. Modified: trunk/docs/pdds/pdd03_calling_conventions.pod == --- trunk/docs/pdds/pdd03_calling_conventions.pod (original) +++ trunk/docs/pdds/pdd03_calling_conventions.pod Mon Mar 13 15:41:32 2006 @@ -123,15 +123,19 @@ The meaning of this bit is undefined when applied to integer, number, and string values. -6 MAYBE_FLAT ((DEPRECATED)) - DEPRECATED - DO NOT USE - If: -(a) this bit is set on a PMC value; and, -(b) the PMC is an aggregate or a scalar containing a reference -to an aggregate; and, -(c) the called function has a slurpy flag on the corresponding -parameter; - then, pretend FLAT bit was set. +6 MAYBE_FLAT + If this bit is set on a PMC value, and: +(a) the PMC is either an aggregate or a scalar containing a +reference to an aggregate, and +(b) the target register has the SLURPY bit set, + then pass the PMC value as a list of values, in these ways: +(a) if the value is an array, pass its elements in the normal +way (FLAT style); +(b) if the value is a hash, pass its elements as a list of +key/value pairs contained in HLL-specific 'pair' PMCs. + The meaning of this bit is undefined when applied to integer, + number, and string values. It may not be combined with the + NAMED bit. 7 (unused)
[svn:parrot-pdd] r12283 - trunk/docs/pdds
Author: chip
Date: Sun Apr 16 20:33:54 2006
New Revision: 12283
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
* Added requirement that ."load_library"() throw an exception on
failure. Also noted that the exception is only covering for the lack of a
universal error PMC, which I would prefer for this API if I had it. >>TODO
* Eliminated "::" from the document except in Perl code examples. People are
going to keep imitating those colons if we leave them in.
Question for readers: is "use tcl:Foo::Bar" (note the single colon) standard
Perl 6 or did some other editor make that up? Perspiring minds want to know.
* Clarified but did not change suggestions on typed interface for Perl.
(Doesn't mean they won't change eventually; Audrey Tang has suggested
semantics that could sidestep many sigil issues. In any case, these are
just suggestions.)
* [cosmetic] Rewrapped at correct width.
Modified: trunk/docs/pdds/pdd21_namespaces.pod
==
--- trunk/docs/pdds/pdd21_namespaces.pod(original)
+++ trunk/docs/pdds/pdd21_namespaces.podSun Apr 16 20:33:54 2006
@@ -47,12 +47,18 @@
initialize the runtime current namespace as well as determine where to store
compiled symbols.)
-=head2 namespace separator: "::"
+=head2 namespace indexing syntax
-In this document, "::" indicates namespace nesting. For example, "a::b" means
-"the namespace 'b' inside the namespace 'a'". In Parrot, nesting is actually
-denoted by other means (e.g. multidimensional hash keys), but writing ["a";
"b"]
-is harder to both write and read.
+Namespaces are denoted in Parrot as either simple strings or (potentially)
+multimentional hash keys.
+
+A non-nested namespace may appear in Parrot source code as the string
+C<"a"> or the key C<["a"]>.
+
+A nested namespace "b" inside the namespace "a" will appear as the key
+C<["a"; "b"]>.
+
+(There is no limit to namespace nesting.)
=head1 IMPLEMENTATION
@@ -79,6 +85,11 @@
unicode encoding. The reasons for these restrictions is to allow compilers
to remain completely ignorant of each other.
+=item True Root Namespace
+
+The true root namespace is available only via introspection with the
+C opcode, e.g. C<$P0 = interpinfo .NAMESPACE_ROOT>.
+
=item HLL Implementation Namespaces
Each HLL must store implementation internals (private items) in a namespace
@@ -148,8 +159,9 @@
Store $P0 as a variable under the name of $S0.
-IMPLEMENTATION NOTE: perl6::namespace.add_var may choose to check which parts
-of the variable interface are implemented by $P0 so it can decide on an
+IMPLEMENTATION NOTE: Perl namespace implementations may choose to implement
+add_var() by checking what which parts of the variable interface are
+implemented by $P0 (scalar, array, and/or hash) so it can decide on an
appropriate sigil.
=item del_namespace($S0)
@@ -168,9 +180,11 @@
Find the sub, namespace, or variable named $S0.
-IMPLEMENTATION NOTE: perl6::namespace.find_var should check all variable
-sigils, but the order is not to be counted on by users. If you're planning to
-let Python code see your module, don't have both C and C.
+IMPLEMENTATION NOTE: Perl namespace implementations should implement
+find_var() to check all variable sigils, but the order is not to be counted on
+by users. If you're planning to let Python code see your module, you should
+avoid exporting both C and C. (Well, you might want to
+consider not exporting variables at all, but that's a style issue.)
=item export_to($P0, $P1)
@@ -188,10 +202,16 @@
For example, Perl's pragmata are implemented as exports, and they don't
actually export anything.
-IMPLEMENTATION EXAMPLES: Perl 6 C will import all
-the commands that start with 'c' from the given Tcl namespace into the current
-Perl namespace. Regardless of whether 'c*' is a Perl 6 style export pattern,
-it I a valid Tcl export pattern.
+IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some Tcl module
+with an import pattern of "c*" -- something that might be expressed in Perl 6
+as C. This operation would import all the commands
+that start with 'c' from the given Tcl namespace into the current Perl
+namespace. This is so because, regardless of whether 'c*' is a Perl 6 style
+export pattern, it I a valid Tcl export pattern.
+
+{XXX - Is the ':' for HLL approved or just proposed? Somebody familiar with
+Perl 6 please fix the example in the preceding paragraph to use the currently
+planned syntax for importing modules from other languages.}
IMPLEMENTATION NOTE: Most namespace export_to implementations will restrict
themselves to using the t
[svn:parrot-pdd] r12284 - trunk/docs/pdds
Author: chip
Date: Sun Apr 16 21:21:53 2006
New Revision: 12284
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
* Documented clearly & consistently that all namespace opcodes start their
search in the HLL root namespace, *not* at the global root.
* Added a second namespace method to the compiler API:
get_namespace(["namespace", "elements", ...])
I'm still not sure how we ended up with methods on compilers
to support namespace operations, but either somebody did it and I have a
bad memory, or I did it and I have a *really* bad memory. Seems like a
workable idea though.
* Amended docs to consistently include second parameter to compiler method:
load_library(["namespace", ...], control)
* Fixed PIR translation of sample Perl 6 code importing from Tcl.
Modified: trunk/docs/pdds/pdd21_namespaces.pod
==
--- trunk/docs/pdds/pdd21_namespaces.pod(original)
+++ trunk/docs/pdds/pdd21_namespaces.podSun Apr 16 21:21:53 2006
@@ -88,7 +88,7 @@
=item True Root Namespace
The true root namespace is available only via introspection with the
-C opcode, e.g. C<$P0 = interpinfo .NAMESPACE_ROOT>.
+C opcode, e.g. C<$P0 = interpinfo .INTERPINFO_NAMESPACE_ROOT>.
=item HLL Implementation Namespaces
@@ -245,6 +245,23 @@
=over 4
+=item get_namespace($P0)
+
+Ask this compiler to find its namespace named by the elements of the array in
+$P0. Returns namespace PMC on success and null PMC on failure. Note that a
+null PMC or an empty array requests the HLL's base namespace.
+
+This method allows other HLLs to know one name (the HLL) and then work with
+that HLL's modules without having to know the name it chose for its namespace
+tree. (If you really want to know the name, the name() method should work on
+the returned namespace PMC.)
+
+Note that this method is basically a convenience and/or performance hack, as
+it does the equivalent of C followed by
+zero or more calls to .find_namespace(). However, any compiler is
+free to cheat if it doesn't get caught, e.g. to use the untyped namespace
+interface if the language doesn't mangle namespace names.
+
=item load_library($P0, $P1)
Ask this compiler to load a library/module named by the elements of the array
@@ -280,6 +297,10 @@
=head2 Namespace Opcodes
+Note that all namespace opcodes operate from the local HLL root namespace.
+Navigating outside one's own HLL namespace requires either the C opcode or the get_namespace() compiler PMC method.
+
=over 4
=item add_namespace $P0, $P1
@@ -433,12 +454,15 @@
.sub main :main
$P0 = find_name "&foo"
-$P1 = get_namespace ["perl6"; "Foo"]
+$P1 = get_namespace ["Foo"]
+
# A smart perl6 compiler would emit this,
# because it knows that Foo is a perl6 namespace:
-# $P1["&bar"] = $P0
-# But a naive one would emit this:
+$P1["&bar"] = $P0
+
+# But a naive perl6 compiler would emit this:
$P1.add_sub("bar", $P0)
+
end
.end
@@ -454,16 +478,22 @@
use tcl:Some::Module 'w*'; # XXX - is ':' after HLL standard Perl 6?
write("this is a tcl command");
-PIR:
+PIR (without error checking):
.sub main :main
.local pmc tcl
+.local pmc ns
tcl = compreg "tcl"
-tcl.load_library("Some", "Module")
-$P0 = get_namespace
-$P1 = get_namespace ["tcl"; "Some"; "Module"]
-$P1.export_to($P0, 'w*')
-write("this is a tcl command")
+ns = new .Array
+ns = 2
+ns[0] = "Some"
+ns[1] = "Module"
+null $P0
+tcl.load_library(ns, $P0)
+$P0 = tcl.get_namespace(ns)
+$P1 = get_namespace
+$P0.export_to($P1, 'w*')
+"write"("this is a tcl command")
end
.end
[svn:parrot-pdd] r12289 - trunk/docs/pdds
Author: chip Date: Mon Apr 17 08:35:24 2006 New Revision: 12289 Modified: trunk/docs/pdds/pdd21_namespaces.pod Log: Rename name() method to get_name() for consistency and to allow for eventual possibility of set_name(). Modified: trunk/docs/pdds/pdd21_namespaces.pod == --- trunk/docs/pdds/pdd21_namespaces.pod(original) +++ trunk/docs/pdds/pdd21_namespaces.podMon Apr 17 08:35:24 2006 @@ -229,13 +229,15 @@ =over 4 -=item $P0 = name() +=item $P0 = get_name() -Returns the name of the namespace as an array of strings. So if the current -language is Perl 5 and the current Perl 5 namespace is "Some::Module" (that's -Perl 5 syntax), then name() returns an array of "perl5", "Some", "Module". +Gets the name of the namespace as an array of strings. For exmaple, if the +current language is Perl 5 and the current Perl 5 namespace is "Some::Module" +(that's Perl 5 syntax), then get_name() on that namespace returns an array of +"perl5", "Some", "Module". -NOTE: This is a naive method. It does not account for any aliasing. +NOTE: Due to aliasing, this value may be wrong, even if nobody's been playing +around with it. =back
[svn:parrot-pdd] r12706 - in trunk: . docs docs/pdds/clip src/ops src/pmc t/pmc
Author: chip
Date: Tue May 16 13:27:30 2006
New Revision: 12706
Modified:
trunk/docs/pdds/clip/pdd02_vtables.pod
trunk/docs/pdds/clip/pdd15_objects.pod
Changes in other areas also in this revision:
Modified:
trunk/docs/ROADMAP.pod
trunk/docs/vtables.pod
trunk/src/ops/ops.num
trunk/src/ops/pmc.ops
trunk/src/pmc/default.pmc
trunk/src/pmc/parrotobject.pmc
trunk/src/pmc/ref.pmc
trunk/src/pmc/sharedref.pmc
trunk/t/pmc/prop.t
trunk/vtable.tbl
Log:
DELETED: object initialization with simultaneous setting of properties, via
the init_pmc_props() vtable method and its associated opcodes.
Documented: init_pmc() takes an arbitrary initializer with a PMC-specific
meaning, rather than the complicated mess that had been partly documented
but never actually used.
Modified: trunk/docs/pdds/clip/pdd02_vtables.pod
==
--- trunk/docs/pdds/clip/pdd02_vtables.pod (original)
+++ trunk/docs/pdds/clip/pdd02_vtables.pod Tue May 16 13:27:30 2006
@@ -50,29 +50,11 @@
=item void init_pmc(INTERP, PMC* self, PMC* initializer)
-This form of the init method takes a single initializer parameter. The
-initializer is an array that contains keys and values. The meaning of the keys
-and their corresponding values is left up to the PMC.
+This form of PMC initialization takes a single initializer parameter. The
+initializer is an arbitrary PMC whose contents are interpreted by the target
+PMC in an arbitrary fashion. Passing NULL is permitted by Parrot.
-Keys are either strings or integers. If strings, the PMC is responsible for
-figuring out what the string represents. If integers, it means the meaning has
-been pre-figured based on meta-information from the class.
-
-For example, if a class has the known properties "Size", "Dimension" and
-"Color", they may be assigned the values 100, 101, and 102. If the creator of
-the PMC knows enough about the class to make the translation to numbers it may;
-otherwise, the raw strings may be used. So, for the declaration:
-
- my @foo Size(12), Dimension(3), Color("Green");
-
-the init array may be [100, 12, 101, 3, 102, "Green"] or ["Size", 12,
-"Dimension", 3, "Color", "Green"]. Note that, in all cases, the array is an
-array of PMCs. (So you get either an int PMC or a string PMC in the list of
-keys).
-
-=item void init_pmc_props(INTERP, PMC* self, PMC* initializer, PMC* properties)
-
-XXX: what does this do?
+NOTE: It is strongly suggested that init_pmc(NULL) be equivalent to init().
=item void morph(INTERP, PMC* self, INTVAL type)
Modified: trunk/docs/pdds/clip/pdd15_objects.pod
==
--- trunk/docs/pdds/clip/pdd15_objects.pod (original)
+++ trunk/docs/pdds/clip/pdd15_objects.pod Tue May 16 13:27:30 2006
@@ -539,7 +539,12 @@
=item __init_pmc
-=item __init_pmc_props
+Alternative entry point called when object is first created. Accepts a PMC
+parameter used to initialize the given object. Interpretation of the PMC is
+PMC-specific.
+
+NOTE: It is strongly suggested that init_pmc(PMCNULL) be equivalent to
+init(), though there will of necessity be exceptions.
=item __morph
[svn:parrot-pdd] r12774 - trunk/docs/pdds/clip
Author: chip Date: Tue May 23 11:06:17 2006 New Revision: 12774 Modified: trunk/docs/pdds/clip/pdd23_exceptions.pod Log: Half-done. The new opcodes and directives are certain, and can be the basis of implementation work immediately. Modified: trunk/docs/pdds/clip/pdd23_exceptions.pod == --- trunk/docs/pdds/clip/pdd23_exceptions.pod (original) +++ trunk/docs/pdds/clip/pdd23_exceptions.pod Tue May 23 11:06:17 2006 @@ -3,7 +3,7 @@ =head1 NAME -docs/pdds/clip/pdd23_exceptions.pod - Parrot Exceptions +docs/pdds/pdd23_exceptions.pod - Parrot Exceptions =head1 ABSTRACT @@ -16,169 +16,108 @@ =head1 DESCRIPTION -An exception system gives user-developed code control over how run-time -error conditions are handled. Exceptions are errors or unusual -conditions that require special processing. An exception handler -performs the necessary steps to appropriately respond to a particular -kind of exception. +An exception system gives user-developed code control over how run-time error +conditions are handled. Exceptions are errors or unusual conditions that +require special processing. An exception handler performs the necessary steps +to appropriately respond to a particular kind of exception. + +Parrot is designed to support dynamic languages, but Parrot compromises the +principle of dynamic behavior when necessary. For example, Parrot requires any +given subroutine to be fully compiled before it can be called. + +Since the structure and content of a compiled subroutine are fixed at compile +time, it would be wasteful use the dynamic execution of opcodes at runtime to +keep track of meta-information about that structure -- I + +=head2 Exception PIR Directives + +These are the PIR directives relevant to exceptions and exception handlers: + +=over + +=item B<.begin_eh I> + +A C<.begin_eh> directive marks the beginning of a span of opcodes which the +programmer expects to throw an exception. If an exception occurs in the +execution of the given opcode span, Parrot will transfer control to I. + +[XXX - Is a label a good approach? Treating exception handlers as label jumps +rather than full subroutines may be error-prone, but having the lexical stack +conveniently at hand is worth a lot.] + +=item B<.end_eh> + +A C<.end_eh> marks the end of the most recent (innermost) still-open exception +handler opcode span. + +=back =head2 Exception Opcodes These are the opcodes relevant to exceptions and exception handlers: -=over +=item B> + +The C opcode throws the given PMC as an exception. + +Any PMC can be thrown, as long as you're prepared to catch it. If there's any +chance of cross-language calls -- and in a Parrot environment, cross-language +operations are kind of the point -- then be prepared to catch object of +classes you would never throw yourself. + +However, it is I for inter-HLL operation that any +thrown PMC that can possibly escape your private sandbox should meet the +minimal interface requirements of the C class. -=item * +=item B -C creates an exception handler and pushes it onto the control -stack. It takes a label (the location of the exception handler) as its -only argument. [Is this right? Treating exception handlers as label -jumps rather than full subroutines is error-prone.] - -=item * - -C removes the most recently added exception from the control -stack. - -=item * - -C throws an exception object. - -=item * - -C rethrows an exception object. It can only be called from -inside an exception handler. - -=item * - -C throws an exception. It takes two arguments, one for the severity -of the exception and one for the type of exception. - -If the severity is C, it exits via a call to -C<_exit($2)>, which is not a catchable exception. - -These are the constants defined for severity: - - 0EXCEPT_NORMAL - 1EXCEPT_WARNING - 2EXCEPT_ERROR - 3EXCEPT_SEVERE - 4EXCEPT_FATAL - 5EXCEPT_DOOMED - 6EXCEPT_EXIT - -These are the constants defined for exception types: - - 0E_Exception - 1E_SystemExit - 2E_StopIteration - 3E_StandardError - 4E_KeyboardInterrupt - 5E_ImportError - 6E_EnvironmentError - 7E_IOError - 8E_OSError - 9E_WindowsError - 10 E_VMSError - 11 E_EOFError - 12 E_RuntimeError - 13 E_NotImplementedError - 14 E_LibraryNotLoadedError - 15 E_NameError - 16 E_UnboundLocalError - 17 E_AttributeError - 18 E_SyntaxError - 19 E_IndentationError - 20 E_TabError - 21 E_TypeError - 22 E_AssertionError - 23 E_LookupError - 24 E_IndexError - 25 E_KeyError - 26 E_ArithmeticError - 27 E_OverflowError - 28 E_ZeroDivisionError - 29 E_FloatingPointError - 30 E_ValueError - 31 E_UnicodeError - 32 E_UnicodeEncodeError - 33 E_UnicodeDecodeError - 34 E_UnicodeTranslateError - 35 E_ReferenceError - 36
[svn:parrot-pdd] r13070 - trunk/docs/pdds/clip
Author: chip
Date: Fri Jun 30 13:10:33 2006
New Revision: 13070
Modified:
trunk/docs/pdds/clip/pdd23_exceptions.pod
Log:
Overhaul.
Take _that_, Coke!
Modified: trunk/docs/pdds/clip/pdd23_exceptions.pod
==
--- trunk/docs/pdds/clip/pdd23_exceptions.pod (original)
+++ trunk/docs/pdds/clip/pdd23_exceptions.pod Fri Jun 30 13:10:33 2006
@@ -1,6 +1,9 @@
# Copyright (C) 2001-2006, The Perl Foundation.
# $Id$
+{{ NOTE: "rethrow", and "pushaction" are removed, and "die" is different }}
+{{ TODO: enable backtrace }}
+
=head1 NAME
docs/pdds/pdd23_exceptions.pod - Parrot Exceptions
@@ -16,143 +19,311 @@
=head1 DESCRIPTION
-An exception system gives user-developed code control over how run-time error
-conditions are handled. Exceptions are errors or unusual conditions that
-require special processing. An exception handler performs the necessary steps
-to appropriately respond to a particular kind of exception.
-
-Parrot is designed to support dynamic languages, but Parrot compromises the
-principle of dynamic behavior when necessary. For example, Parrot requires any
-given subroutine to be fully compiled before it can be called.
-
-Since the structure and content of a compiled subroutine are fixed at compile
-time, it would be wasteful use the dynamic execution of opcodes at runtime to
-keep track of meta-information about that structure -- I
+I are indications by running code that something unusual -- an
+"exception" to the normal processing -- has occurred. When code detects an
+exceptional condition, it I an exception object. Before this occurs,
+code can register exception I, which are functions (or closures)
+which may (but are not obligated to) I the exception. Some exceptions
+permit continued execution immediately after the I; some don't.
+
+Exceptions transfer control to a piece of code outside the normal flow of
+control. They are mainly used for error reporting or cleanup tasks.
+
+(A digression on terminology: In a system analysis sense, the word "exception"
+usually refers to the exceptional event that requires out-of-band handling.
+However, in Parrot, "exception" also refers to the object that holds all the
+information describing hte exceptional condition: the nature of the exception,
+the error message describing it, and other ancillary information. The
+specific type (class) of an exception object indicates its category.)
-=head2 Exception PIR Directives
+=head2 Exception Opcodes
-These are the PIR directives relevant to exceptions and exception handlers:
+These are the opcodes relevant to exceptions and exception handlers:
-=over
+=item B<< push_eh I >> {{FIXME - Not Available Yet}}
+
+=item B<< push_eh I >>
+
+The C opcode pushes a continuation onto the exception handler stack.
+
+If a I is provided, Parrot automatically performs the equivalent of a
+C operation on the given label, and pushes the resulting
+continuation.
+
+{{FIXME - there is no "newcontinuation" opcode ... yet! In the meantime, you
+have to create the continuations the old-fashioned way.}}
+
+When an exception is thrown, Parrot walks up the stack of active exception
+handlers, invoking each one in turn. (See C and C.)
+
+=item B<< pop_eh >>
+
+The C opcode removes the most recently pushed exception handler from
+the control stack.
+
+=item B<< throw I >>
+
+Throw an exception consisting of the given I PMC. Active exception
+handlers (if any) will be invoked with I as the only parameter.
+
+Throwing an exception with C is a one-way trip (unless you have made
+other arrangements) because Parrot does not take a continuation after this
+opcode. (But see B below.)
+
+Any type of PMC can be thrown as an exception. However, if there's any chance
+of cross-language calls -- and in a Parrot environment, cross-language
+operations are kind of the point -- then you should be prepared to catch
+object of classes you would never have thrown yourself.
-=item B<.begin_eh I>
+That said, it is I that any thrown PMC that can
+possibly escape your private sandbox should meet the minimal interface
+requirements of the C class, described below.
-A C<.begin_eh> directive marks the beginning of a span of opcodes which the
-programmer expects to throw an exception. If an exception occurs in the
-execution of the given opcode span, Parrot will transfer control to I.
+=item B<< throwcc I >>
-[XXX - Is a label a good approach? Treating exception handlers as label jumps
-rather than full subroutines may be error-prone, but having the lexical stack
-conveniently at hand is worth a lot.]
+Throw an exception consisting of the given I PMC after taking a
+continuation at the next opcode. Active exception handlers (if any) will be
+invoked with I and the given continuation as parame
[svn:parrot-pdd] r13071 - in trunk/docs/pdds: . clip
Author: chip Date: Fri Jun 30 13:12:26 2006 New Revision: 13071 Added: trunk/docs/pdds/pdd23_exceptions.pod - copied unchanged from r13070, /trunk/docs/pdds/clip/pdd23_exceptions.pod Removed: trunk/docs/pdds/clip/pdd23_exceptions.pod Log: Rename pdd23 into docs/pdds.
[svn:parrot-pdd] r13092 - trunk/docs/pdds
Author: chip
Date: Sat Jul 1 11:26:02 2006
New Revision: 13092
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
* Exception handlers are now closures (or just plain subroutines),
not continuations.
* Eliminate the C opcode, as the handler returning is enough
of a clue that the next handler should be called.
(This change is at Allison & Patrick's request, and in accord with Audrey's
not requesting otherwise. :-))
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 1 11:26:02 2006
@@ -42,26 +42,29 @@
=over
-=item B<< push_eh I >> {{FIXME - Not Available Yet}}
+=item B<< push_eh I >>
-=item B<< push_eh I >>
+=item B<< push_eh I >>
-The C opcode pushes a continuation onto the exception handler stack.
+Push an invocable PMC -- usually a closure or, in rarer cases, a subroutine --
+onto the exception handler stack.
-If a I is provided, Parrot automatically performs the equivalent of a
-C operation on the given label, and pushes the resulting
-continuation.
-
-{{FIXME - there is no "newcontinuation" opcode ... yet! In the meantime, you
-have to create the continuations the old-fashioned way.}}
+If a I is provided, Parrot automatically performs the equivalent of
+a C operation on the given subroutine, and pushes the resulting
+closure.
When an exception is thrown, Parrot walks up the stack of active exception
-handlers, invoking each one in turn. (See C and C.)
+handlers, invoking each one in turn, but still in the dynamic context of the
+exception (i.e. the call stack is I unwound first). See below for more
+detail.
=item B<< pop_eh >>
-The C opcode removes the most recently pushed exception handler from
-the control stack.
+Pop the most recently pushed exception handler off the control stack.
+
+{{ TODO: should we provide a "pop_eh $P0" variant returning the address, since
+it's easy and somebody might find it useful? Or is it more important to
+provide generic control stack introspection? Probably the latter. }}
=item B<< throw I >>
@@ -87,14 +90,15 @@
continuation at the next opcode. Active exception handlers (if any) will be
invoked with I and the given continuation as parameters.
-Exception handlers can resume execution immediately after this opcode by
-executing the C opcode, and then invoking the given continuation.
-
-{{TODO: May the continuation be invoked with values, or in other words, can
-throwcc return a value?}}
-
-Except for the taking of a continuation which is passed to exception handlers,
-C is just like C.
+Except for its taking of a continuation which is then passed to exception
+handlers, C is just like C. This opcode is useful for
+exceptions that are more like warnings or notices than errors.
+
+Exception handlers can resume execution immediately after the C
+opcode by executing the C opcode, and then invoking the given
+continuation which they receive as a paremter. That continuation must be
+invoked with no parameters; in other words, C may I return a
+value.
=item B ]>
@@ -119,17 +123,12 @@
as a status to its embedded environment, or when running standalone,
to execute the C function C)>.
-=item B<< rethrow >>
-
-While handling an exception, stop execution and move on to the next exception
-handler, if any. This opcode is an exception handler's way of telling Parrot
-that it cannot handle the exception.
-
=item B<< caught >>
-While handling an exception, tell Parrot that the exception has been handled
-and should be removed from the stack of active exceptions. This opcode is an
-exception handler's way of telling Parrot that it has handled the exception.
+While handling an exception, tell Parrot that the exception has been caught
+(handled) and should be removed from the stack of active exceptions. This
+opcode is an exception handler's way of telling Parrot that it has handled the
+exception.
=back
@@ -146,20 +145,22 @@
containing pointer to exception handler block
and exception PMC
(and possibly a continuation)
- invoke the handler's continuation
+ invoke the handler
+(note: this is still in the thrower's dynamic context)
-=item C
+=item if the handler returns normally:
find the "exception handling in progress" record
find the next exception handler
if found,
- invoke its continuation
- else if there is a continuation in the Exception Record (from C),
- invoke it (i.e. resume execution)
+ invoke it
+ else if there is a continuation in the Exception Record
+(because the throwing opcode was C),
+ invoke the ER's continuation (i.e. resume executio
[svn:parrot-pdd] r13093 - trunk/docs/pdds
Author: chip Date: Sat Jul 1 11:26:44 2006 New Revision: 13093 Modified: trunk/docs/pdds/pdd23_exceptions.pod Log: oops, restore namespace on exception class in example code Modified: trunk/docs/pdds/pdd23_exceptions.pod == --- trunk/docs/pdds/pdd23_exceptions.pod(original) +++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 1 11:26:44 2006 @@ -356,8 +356,8 @@ $P0 = new String $P0 = "something bad happened" - $P1 = new ['exception'], $P0 # create new exception object - throw $P1 # throw it + $P1 = new ['parrot';'exception'], $P0 # create new exception object + throw $P1 # throw it Exceptions are designed to work with the Parrot calling conventions. Since the return addresses of C subroutine calls and exception
[svn:parrot-pdd] r13094 - trunk/docs/pdds
Author: chip
Date: Sat Jul 1 11:30:02 2006
New Revision: 13094
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
rename 'caught' opcode to 'handled' for obscure reasons
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podSat Jul 1 11:30:02 2006
@@ -95,12 +95,12 @@
exceptions that are more like warnings or notices than errors.
Exception handlers can resume execution immediately after the C
-opcode by executing the C opcode, and then invoking the given
+opcode by executing the C opcode, and then invoking the given
continuation which they receive as a paremter. That continuation must be
invoked with no parameters; in other words, C may I return a
value.
-=item B ]>
+=item B<< die [ I ] >>
The C opcode throws an exception of type C with a
payload of I. If I is a string register, the exception
@@ -109,26 +109,25 @@
{{ TODO: What is the default when no I is given? }}
-If this exception is not caught, it results in Parrot returning an error
+If this exception is not handled, it results in Parrot returning an error
indication and the stringification of I to its embedding environment.
When running standalone, this means writing the stringification of I
to the standard error and executing the standard C function C.
-=item B ]>
+=item B<< exit [ I ] >>
Throw an exception of type C with a payload of I,
which defaults to zero, as an Integer PMC.
-If not caught, this exception results in Parrot returning I
+If not handled, this exception results in Parrot returning I
as a status to its embedded environment, or when running standalone,
to execute the C function C)>.
-=item B<< caught >>
+=item B<< handled >>
-While handling an exception, tell Parrot that the exception has been caught
-(handled) and should be removed from the stack of active exceptions. This
-opcode is an exception handler's way of telling Parrot that it has handled the
-exception.
+While handling an exception, tell Parrot that the exception has been handled
+and should be removed from the stack of active exceptions. This opcode is an
+exception handler's way of telling Parrot that it has handled the exception.
=back
@@ -160,7 +159,7 @@
else,
terminate program a la C
-=item C opcode
+=item C opcode
pop and destroy Exception Record
[svn:parrot-pdd] r13097 - trunk/docs/pdds
Author: chip Date: Sat Jul 1 12:27:31 2006 New Revision: 13097 Modified: trunk/docs/pdds/pdd21_namespaces.pod Log: Consistently describe namespace identifiers accepted by namespace opcodes as either key constants or string arrays, since both of those work in all cases (or should :-)). Modified: trunk/docs/pdds/pdd21_namespaces.pod == --- trunk/docs/pdds/pdd21_namespaces.pod(original) +++ trunk/docs/pdds/pdd21_namespaces.podSat Jul 1 12:27:31 2006 @@ -18,8 +18,8 @@ =item - Namespaces should be hierarchical -=item - Add a get_namespace opcode (that takes an array or a multidimensional -hash index) +=item - The get_namespace opcode takes a multidimensional hash key or an array +of name strings =item - Namespaces follow the semantics of the HLL in which they're defined @@ -236,8 +236,8 @@ (that's Perl 5 syntax), then get_name() on that namespace returns an array of "perl5", "Some", "Module". -NOTE: Due to aliasing, this value may be wrong, even if nobody's been playing -around with it. +NOTE: Due to aliasing, this value may be wrong -- i.e. it may disagree with +the namespace name with which you found the namespace in the first place. =back @@ -307,40 +307,46 @@ =item add_namespace $P0, $P1 -Add the namespace PMC $P1 as the namespace $P0 (an array of names or a -multidimensional hash index). +Add the namespace PMC $P1 under the name denoted by $P0 (an array of names or +a multidimensional hash index). =item del_namespace $P0 Delete the namespace $P0 (an array of names or a multidimensional hash index). -=item $P0 = find_global $P1, $S0 - -=item $P0 = find_global $S0 +=item $P0 = get_namespace -Find $P0 as the variable $S0 in the current namespace. or in $P1, relative -to the HLL root namespace. +Set $P0 to the current namespace (i.e. the namespace of the currently +executing subroutine). =item $P0 = get_namespace $P1 -=item $P0 = get_namespace +Get the namespace denoted by C<$P1> (an array of names or a multidimensional +hash index) and store it in C<$P0>. -Get the namespace $P1 (an array of names or a multidimensional hash index) or -the current namespace. To get the "Foo::Bar" namespace, one would use this: +Thus, to get the "Foo::Bar" namespace, if the name is known at compile time, +one could use this opcode: - $P0 = split "::", "Foo::Bar" - $P1 = get_namespace $P0 + $P0 = get_namespace ["Foo"; "Bar"] -or this: +or, if the name is not known at compile time, this idiom: + + $P1 = split "::", "Foo::Bar" + $P0 = get_namespace $P1 + +=item $P0 = find_global $P1, $S0 + +=item $P0 = find_global $S0 - $P1 = get_namespace ["Foo"; "Bar"] +Find $P0 as the variable $S0 in the current namespace. or in $P1 (an array of +names or a multidimensional hash index), relative to the HLL root namespace. =item store_global $P1, $S0, $P0 =item store_global $S0, $P0 -Store $P0 as the variable $S0 in the current namespace, or in $P1, relative -to the HLL root namespace. +Store $P0 as the variable $S0 in the current namespace, or in $P1 (an array of +names or a multidimensional hash index), relative to the HLL root namespace. =back
[svn:parrot-pdd] r13098 - trunk/docs/pdds
Author: chip Date: Sat Jul 1 13:00:41 2006 New Revision: 13098 Modified: trunk/docs/pdds/pdd21_namespaces.pod Log: Specify new compiler methods, compiler.'parse_name'(), which allows parsing foreign language names using the foreign language's rules. (per Allison) [Tests Welcome] Modified: trunk/docs/pdds/pdd21_namespaces.pod == --- trunk/docs/pdds/pdd21_namespaces.pod(original) +++ trunk/docs/pdds/pdd21_namespaces.podSat Jul 1 13:00:41 2006 @@ -247,11 +247,20 @@ =over 4 +=item $P0 = parse_name($S0) + +Parse the name in $S0 using the rules specific to the given compiler, and +return an array of individual name elements. + +For example, a Java compiler would turn 'a.b.c' to ['a','b','c'], while a Perl +compiler would turn 'a::b::c' into the same result. Meanwhile, due to Perl's +sigil rules, '$a::b::c' would become ['a','b','$c']. + =item get_namespace($P0) -Ask this compiler to find its namespace named by the elements of the array in -$P0. Returns namespace PMC on success and null PMC on failure. Note that a -null PMC or an empty array requests the HLL's base namespace. +Ask this compiler to find its namespace which is named by the elements of the +array in $P0. Returns namespace PMC on success and null PMC on failure. Note +that a null PMC or an empty array requests the HLL's base namespace. This method allows other HLLs to know one name (the HLL) and then work with that HLL's modules without having to know the name it chose for its namespace
[svn:parrot-pdd] r13170 - in trunk: docs/pdds include/parrot src src/ops src/pmc t/op t/pmc t/src
Author: chip
Date: Wed Jul 5 17:31:15 2006
New Revision: 13170
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Changes in other areas also in this revision:
Modified:
trunk/include/parrot/global.h
trunk/include/parrot/hll.h
trunk/src/builtin.c
trunk/src/global.c
trunk/src/global_setup.c
trunk/src/hll.c
trunk/src/mmd.c
trunk/src/objects.c
trunk/src/ops/var.ops
trunk/src/pmc/boolean.pmc
trunk/src/pmc/default.pmc
trunk/src/pmc/parrotinterpreter.pmc
trunk/t/op/globals.t
trunk/t/pmc/globals.t
trunk/t/pmc/namespace.t
trunk/t/src/compiler.t
trunk/t/src/extend.t
Log:
* No longer support a namespace PMC as the second parameter to find_global
and store_global. These opcodes require namespaces to be designated
(named) with a string, a key, or an array of strings.
User code that already has a namespace PMC, should use the pdd21 namespace
interface.
* Revamp the Parrot_{find,store}_global functions, each of which now has
several variations for convenience in various circumstances:
PMC *Parrot_find_namespace* - find an existing namespace PMC
PMC *Parrot_make_namespace* - find an existing namespace PMC,
or if not found, create it
PMC *Parrot_find_global*- fetch a global from an existing namespace
PMC *Parrot_store_global* - store a possibly new global into a possibly
new namespace
and helper functions for opcodes:
PMC *Parrot_find_global_op - find a global, optionally throwing an
exception on failure
PMC *Parrot_find_name_op- find a variable which could be a lexical or
a global in one of a few namespaces,
optionally throwing an exception on failure
Modified: trunk/docs/pdds/pdd21_namespaces.pod
==
--- trunk/docs/pdds/pdd21_namespaces.pod(original)
+++ trunk/docs/pdds/pdd21_namespaces.podWed Jul 5 17:31:15 2006
@@ -343,19 +343,29 @@
$P1 = split "::", "Foo::Bar"
$P0 = get_namespace $P1
-=item $P0 = find_global $P1, $S0
-
=item $P0 = find_global $S0
-Find $P0 as the variable $S0 in the current namespace. or in $P1 (an array of
-names or a multidimensional hash index), relative to the HLL root namespace.
+Find $P0 as the variable named $S0 in the current namespace.
-=item store_global $P1, $S0, $P0
+=item $P0 = find_global $S1, $S0
+
+=item $P0 = find_global $P1, $S0
+
+Find $P0 as the variable named $S0 in $S1 (a first-level namespace) or $P1 (an
+array of names or a multidimensional hash index), relative to the HLL root
+namespace.
=item store_global $S0, $P0
-Store $P0 as the variable $S0 in the current namespace, or in $P1 (an array of
-names or a multidimensional hash index), relative to the HLL root namespace.
+Store $P0 as the variable $S0 in the current namespace.
+
+=item store_global $S1, $S0, $P0
+
+=item store_global $P1, $S0, $P0
+
+Store $P0 as the variable $S0 in $S1 (a first-level namespace) or $P1 (an
+array of names or a multidimensional hash index), relative to the HLL root
+namespace. If the given namespace does not exist it is created.
=back
[svn:parrot-pdd] r13183 - in trunk: . compilers/imcc docs docs/dev docs/pdds editor languages/regex languages/tcl src
Author: chip
Date: Thu Jul 6 13:05:47 2006
New Revision: 13183
Modified:
trunk/docs/pdds/pdd00_pdd.pod
Changes in other areas also in this revision:
Modified:
trunk/README
trunk/README.win32.pod
trunk/RELEASE_INSTRUCTIONS
trunk/compilers/imcc/README
trunk/docs/debug.pod
trunk/docs/dev/dod.pod
trunk/docs/faq.pod
trunk/docs/gettingstarted.pod
trunk/docs/glossary.pod
trunk/docs/intro.pod
trunk/docs/parrot.pod
trunk/docs/submissions.pod
trunk/editor/pir-mode.el
trunk/languages/regex/README
trunk/languages/tcl/README.pod
trunk/parrotbug
trunk/src/exceptions.c
Log:
From: Chris Dolan <[EMAIL PROTECTED]>
Subject: Re: [perl #39743] [PATCH] change perl6-internals to parrot-porters in
docs
{ a followup patch will be required if p6i doesn't end up forwarding to p2 }
Modified: trunk/docs/pdds/pdd00_pdd.pod
==
--- trunk/docs/pdds/pdd00_pdd.pod (original)
+++ trunk/docs/pdds/pdd00_pdd.pod Thu Jul 6 13:05:47 2006
@@ -145,8 +145,8 @@
=head2 SUBMISSION CRITERIA
-Proposed PDDs should be submitted to the perl6-internals mailing list (located
-at perl6-internals@perl.org) for discussion, criticism and general kibitzing.
+Proposed PDDs should be submitted to the parrot-porters mailing list (located
+at [EMAIL PROTECTED]) for discussion, criticism and general kibitzing.
Acceptance of a particular PDD is ultimately up to the Parrot Architect.
=head2 PDD TRANSLATIONS
[svn:parrot-pdd] r14416 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 10:42:07 2006
New Revision: 14416
Added:
trunk/docs/pdds/pdd07_codingstd.pod (contents, props changed)
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Move pdd07 out of clip
Added: trunk/docs/pdds/pdd07_codingstd.pod
==
--- (empty file)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 10:42:07 2006
@@ -0,0 +1,930 @@
+# Copyright (C) 2001-2006, The Perl Foundation.
+# $Id$
+
+=head1 NAME
+
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+Code
+
+=head1 ABSTRACT
+
+This document describes the various rules, guidelines and advice for those
+wishing to contribute to the source code of Parrot, in such areas as code
+structure, naming conventions, comments etc.
+
+=head1 DESCRIPTION
+
+One of the criticisms of Perl 5 is that its source code is impenetrable to
+newcomers, due to such things as inconsistent or obscure variable naming
+conventions, lack of comments in the source code, and so on. We don't intend
+to make the same mistake when writing Parrot. Hence this document.
+
+We define three classes of conventions. Those that say I are mandatory,
+and code will not be accepted (apart from in exceptional circumstances) unless
+it follows these rules. Those that say I are strong guidelines that
+should normally be followed unless there is a sensible reason to do otherwise.
+Finally, those that say I, are tentative suggestions to be used at your
+discretion.
+
+Note this particular PDD makes some recommendations that are specific to the C
+programming language. This does not preclude Parrot (or Perl 6) being
+implemented in other languages, but in this case, additional PDDs may need to
+be authored for the extra language-specific features.
+
+=head1 IMPLEMENTATION
+
+=head2 Coding style
+
+The following I apply:
+
+=over 4
+
+=item *
+
+4 column indents for code and 2 column indents for nested CPP #directives. All
+indentation must consist of spaces, no tabs (for ease of patching).
+
+There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
+outermost _GUARD #ifdefs cause the level of indenting to increase.
+
+To ensure that tabs aren't inadvertently used for indentation, the following
+boilerplate code must appear at the bottom of each source file. (This rule may
+be rescinded if I'm ever threatened with a lynching)
+
+ /*
+* Local variables:
+* c-indentation-style: bsd
+* c-basic-offset: 4
+* indent-tabs-mode: nil
+* End:
+*
+* vim: expandtab shiftwidth=4:
+*/
+
+
+=item *
+
+Any other tabs are assumed to be on an 8-character boundary.
+
+=item *
+
+ANSI C function prototypes
+
+=item *
+
+"K&R" style for indenting control constructs: ie the closing C<}> should line
+up with the opening C etc.
+
+=item *
+
+When a conditional spans multiple lines, the opening C<{> must line up with the
+C or C, or be at the end-of-line otherwise.
+
+=item *
+
+Uncuddled Cs: ie avoid C<} else {>
+
+=item *
+
+C-style comments only (C). Not all C compilers handle
+C++-style comments.
+
+=item *
+
+Mark places that need to be revisited with XXX (and preferably your initials
+too), and revisit often!
+
+=item *
+
+In function definitions, the name starts in column 0, with the return type on
+the previous line.
+
+=item *
+
+However, in function declarations (in header files) the return type is kept on
+the same line.
+
+=item *
+
+Variable names should be included for all function parameters in the function
+declarations. These names should match the parameters in the function
+definition.
+
+=item *
+
+Single space after keywords that are followed by C<()>, eg C,
+but no space between function name and following C<()>, eg C
+
+=back
+
+The following I apply
+
+=over 4
+
+=item *
+
+Do not exceed 79 columns
+
+=item *
+
+C rather than C
+
+=item *
+
+C rather than C etc.
+
+=item *
+
+Avoid assignments in conditionals, but if they're unavoidable, use Extra paren,
+e.g. C
+
+=item *
+
+Avoid double negatives, eg C<#ifndef NO_FEATURE_FOO>
+
+=item *
+
+Binary operators should have a space on either side; parentheses should not
+have space immediately after the opening paren nor immediately before the
+closing paren, commas should have space after but not before, eg
+
+x = (a + b) * f(c, d / e)
+
+=item *
+
+Long lines should be split before an operator so that it is immediately obvious
+when scanning the LHS of the code that this has happened, and two extra levels
+of indent should be used.
+
+=item *
+
+and/or split on matching parens, with the content on separate line(s) and with
+one extra indent:
+
+do_arbitrary_function(
+list_of_parameters_with_long_names, or_complex_subexpression(
+of_more_params, or_expressions + 1
+)
+);
+
+=back
+
+To enforce the spac
[svn:parrot-pdd] r14419 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 10:42:52 2006
New Revision: 14419
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
About 25% done with update of pdd07.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 10:42:52 2006
@@ -3,9 +3,13 @@
=head1 NAME
-docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
Code
+=head1 VERSION
+
+$Revision$
+
=head1 ABSTRACT
This document describes the various rules, guidelines and advice for those
@@ -19,316 +23,306 @@
conventions, lack of comments in the source code, and so on. We don't intend
to make the same mistake when writing Parrot. Hence this document.
-We define three classes of conventions. Those that say I are mandatory,
-and code will not be accepted (apart from in exceptional circumstances) unless
-it follows these rules. Those that say I are strong guidelines that
-should normally be followed unless there is a sensible reason to do otherwise.
-Finally, those that say I, are tentative suggestions to be used at your
-discretion.
-
-Note this particular PDD makes some recommendations that are specific to the C
-programming language. This does not preclude Parrot (or Perl 6) being
-implemented in other languages, but in this case, additional PDDs may need to
-be authored for the extra language-specific features.
-
-=head1 IMPLEMENTATION
-
-=head2 Coding style
-
-The following I apply:
+We define three classes of conventions:
=over 4
-=item *
-
-4 column indents for code and 2 column indents for nested CPP #directives. All
-indentation must consist of spaces, no tabs (for ease of patching).
+=item I<"must">
-There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
-outermost _GUARD #ifdefs cause the level of indenting to increase.
+Items labelled I are mandatory; and code will not be accepted (apart
+from in exceptional circumstances) unless it obeys them.
-To ensure that tabs aren't inadvertently used for indentation, the following
-boilerplate code must appear at the bottom of each source file. (This rule may
-be rescinded if I'm ever threatened with a lynching)
+=item I<"should">
- /*
-* Local variables:
-* c-indentation-style: bsd
-* c-basic-offset: 4
-* indent-tabs-mode: nil
-* End:
-*
-* vim: expandtab shiftwidth=4:
-*/
+Items labelled I are strong guidelines that should normally be
+followed unless there is a sensible reason to do otherwise.
+=item I<"may">
-=item *
-
-Any other tabs are assumed to be on an 8-character boundary.
-
-=item *
-
-ANSI C function prototypes
+Items labelled I are tentative suggestions to be used at your discretion.
-=item *
+=back
-"K&R" style for indenting control constructs: ie the closing C<}> should line
-up with the opening C etc.
+Note that since Parrot is substantially implemented in C, these rules apply to
+C language source code unless otherwise specified.
-=item *
+=head1 IMPLEMENTATION
-When a conditional spans multiple lines, the opening C<{> must line up with the
-C or C, or be at the end-of-line otherwise.
-=item *
+=head2 Language Standards and Portability
-Uncuddled Cs: ie avoid C<} else {>
+=over 4
=item *
-C-style comments only (C). Not all C compilers handle
-C++-style comments.
+C code must generally depend on only those language and library features
+specified by the ISO C89 standard.
-=item *
+In addition, C code may assume that any pointer value can be coerced to an
+integral type (no smaller than typedef C in Parrot), then back to its
+original type, without loss.
-Mark places that need to be revisited with XXX (and preferably your initials
-too), and revisit often!
+C code that makes assumptions beyond these must depend on the configuration
+system, either to not compile an entire non-portable source where it will not
+work, or to provide an appropriate #ifdef macro.
-=item *
-
-In function definitions, the name starts in column 0, with the return type on
-the previous line.
+{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
=item *
-However, in function declarations (in header files) the return type is kept on
-the same line.
+Perl code must be written for Perl 5.6.1 and all later versions.
-=item *
+Perl code may use features not available in Perl 5.6.1 only if it is not vital
+to Parrot, and if it uses C<$^O> and C<$]> to degrade or fail gracefully when
+it is run where the features it depends on are not available.
-Variable names should be included for all function parameters in the fu
[svn:parrot-pdd] r14432 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 15:00:42 2006
New Revision: 14432
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Move pdd07 out of clip
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 15:00:42 2006
@@ -3,13 +3,9 @@
=head1 NAME
-docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
Code
-=head1 VERSION
-
-$Revision$
-
=head1 ABSTRACT
This document describes the various rules, guidelines and advice for those
@@ -23,306 +19,316 @@
conventions, lack of comments in the source code, and so on. We don't intend
to make the same mistake when writing Parrot. Hence this document.
-We define three classes of conventions:
+We define three classes of conventions. Those that say I are mandatory,
+and code will not be accepted (apart from in exceptional circumstances) unless
+it follows these rules. Those that say I are strong guidelines that
+should normally be followed unless there is a sensible reason to do otherwise.
+Finally, those that say I, are tentative suggestions to be used at your
+discretion.
+
+Note this particular PDD makes some recommendations that are specific to the C
+programming language. This does not preclude Parrot (or Perl 6) being
+implemented in other languages, but in this case, additional PDDs may need to
+be authored for the extra language-specific features.
+
+=head1 IMPLEMENTATION
+
+=head2 Coding style
+
+The following I apply:
=over 4
-=item I<"must">
+=item *
-Items labelled I are mandatory; and code will not be accepted (apart
-from in exceptional circumstances) unless it obeys them.
+4 column indents for code and 2 column indents for nested CPP #directives. All
+indentation must consist of spaces, no tabs (for ease of patching).
-=item I<"should">
+There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
+outermost _GUARD #ifdefs cause the level of indenting to increase.
-Items labelled I are strong guidelines that should normally be
-followed unless there is a sensible reason to do otherwise.
+To ensure that tabs aren't inadvertently used for indentation, the following
+boilerplate code must appear at the bottom of each source file. (This rule may
+be rescinded if I'm ever threatened with a lynching)
-=item I<"may">
+ /*
+* Local variables:
+* c-indentation-style: bsd
+* c-basic-offset: 4
+* indent-tabs-mode: nil
+* End:
+*
+* vim: expandtab shiftwidth=4:
+*/
-Items labelled I are tentative suggestions to be used at your discretion.
-=back
+=item *
-Note that since Parrot is substantially implemented in C, these rules apply to
-C language source code unless otherwise specified.
+Any other tabs are assumed to be on an 8-character boundary.
-=head1 IMPLEMENTATION
+=item *
+ANSI C function prototypes
-=head2 Language Standards and Portability
+=item *
-=over 4
+"K&R" style for indenting control constructs: ie the closing C<}> should line
+up with the opening C etc.
=item *
-C code must generally depend on only those language and library features
-specified by the ISO C89 standard.
+When a conditional spans multiple lines, the opening C<{> must line up with the
+C or C, or be at the end-of-line otherwise.
-In addition, C code may assume that any pointer value can be coerced to an
-integral type (no smaller than typedef C in Parrot), then back to its
-original type, without loss.
+=item *
+
+Uncuddled Cs: ie avoid C<} else {>
-C code that makes assumptions beyond these must depend on the configuration
-system, either to not compile an entire non-portable source where it will not
-work, or to provide an appropriate #ifdef macro.
+=item *
-{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
+C-style comments only (C). Not all C compilers handle
+C++-style comments.
=item *
-Perl code must be written for Perl 5.6.1 and all later versions.
+Mark places that need to be revisited with XXX (and preferably your initials
+too), and revisit often!
-Perl code may use features not available in Perl 5.6.1 only if it is not vital
-to Parrot, and if it uses C<$^O> and C<$]> to degrade or fail gracefully when
-it is run where the features it depends on are not available.
+=item *
-=back
+In function definitions, the name starts in column 0, with the return type on
+the previous line.
+=item *
-=head2 Code Formatting
+However, in function declarations (in header files) the return type is kept on
+the same line.
-The following I apply:
+=item *
+
+Variable names should be incl
[svn:parrot-pdd] r14435 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 15:01:18 2006
New Revision: 14435
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
About 25% done with update of pdd07.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 15:01:18 2006
@@ -3,9 +3,13 @@
=head1 NAME
-docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
Code
+=head1 VERSION
+
+$Revision$
+
=head1 ABSTRACT
This document describes the various rules, guidelines and advice for those
@@ -19,316 +23,306 @@
conventions, lack of comments in the source code, and so on. We don't intend
to make the same mistake when writing Parrot. Hence this document.
-We define three classes of conventions. Those that say I are mandatory,
-and code will not be accepted (apart from in exceptional circumstances) unless
-it follows these rules. Those that say I are strong guidelines that
-should normally be followed unless there is a sensible reason to do otherwise.
-Finally, those that say I, are tentative suggestions to be used at your
-discretion.
-
-Note this particular PDD makes some recommendations that are specific to the C
-programming language. This does not preclude Parrot (or Perl 6) being
-implemented in other languages, but in this case, additional PDDs may need to
-be authored for the extra language-specific features.
-
-=head1 IMPLEMENTATION
-
-=head2 Coding style
-
-The following I apply:
+We define three classes of conventions:
=over 4
-=item *
-
-4 column indents for code and 2 column indents for nested CPP #directives. All
-indentation must consist of spaces, no tabs (for ease of patching).
+=item I<"must">
-There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
-outermost _GUARD #ifdefs cause the level of indenting to increase.
+Items labelled I are mandatory; and code will not be accepted (apart
+from in exceptional circumstances) unless it obeys them.
-To ensure that tabs aren't inadvertently used for indentation, the following
-boilerplate code must appear at the bottom of each source file. (This rule may
-be rescinded if I'm ever threatened with a lynching)
+=item I<"should">
- /*
-* Local variables:
-* c-indentation-style: bsd
-* c-basic-offset: 4
-* indent-tabs-mode: nil
-* End:
-*
-* vim: expandtab shiftwidth=4:
-*/
+Items labelled I are strong guidelines that should normally be
+followed unless there is a sensible reason to do otherwise.
+=item I<"may">
-=item *
-
-Any other tabs are assumed to be on an 8-character boundary.
-
-=item *
-
-ANSI C function prototypes
+Items labelled I are tentative suggestions to be used at your discretion.
-=item *
+=back
-"K&R" style for indenting control constructs: ie the closing C<}> should line
-up with the opening C etc.
+Note that since Parrot is substantially implemented in C, these rules apply to
+C language source code unless otherwise specified.
-=item *
+=head1 IMPLEMENTATION
-When a conditional spans multiple lines, the opening C<{> must line up with the
-C or C, or be at the end-of-line otherwise.
-=item *
+=head2 Language Standards and Portability
-Uncuddled Cs: ie avoid C<} else {>
+=over 4
=item *
-C-style comments only (C). Not all C compilers handle
-C++-style comments.
+C code must generally depend on only those language and library features
+specified by the ISO C89 standard.
-=item *
+In addition, C code may assume that any pointer value can be coerced to an
+integral type (no smaller than typedef C in Parrot), then back to its
+original type, without loss.
-Mark places that need to be revisited with XXX (and preferably your initials
-too), and revisit often!
+C code that makes assumptions beyond these must depend on the configuration
+system, either to not compile an entire non-portable source where it will not
+work, or to provide an appropriate #ifdef macro.
-=item *
-
-In function definitions, the name starts in column 0, with the return type on
-the previous line.
+{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
=item *
-However, in function declarations (in header files) the return type is kept on
-the same line.
+Perl code must be written for Perl 5.6.1 and all later versions.
-=item *
+Perl code may use features not available in Perl 5.6.1 only if it is not vital
+to Parrot, and if it uses C<$^O> and C<$]> to degrade or fail gracefully when
+it is run where the features it depends on are not available.
-Variable names should be included for all function parameters in the fu
[svn:parrot-pdd] r14436 - in trunk: . docs/pdds editor
Author: chip Date: Tue Sep 5 15:01:35 2006 New Revision: 14436 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Added: trunk/editor/parrot.el (contents, props changed) Modified: trunk/ (props changed) trunk/editor/README.pod Log: Commit initial version of parrot.el, in 'editor' directory as it should be. Update pdd07 and editor/README accordingly. Modified: trunk/docs/pdds/pdd07_codingstd.pod == --- trunk/docs/pdds/pdd07_codingstd.pod (original) +++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 15:01:35 2006 @@ -276,19 +276,17 @@ =head2 Smart Editor Style Support All developers using Emacs must ensure that their Emacs instances load the -elisp source file F before opening Parrot source files. -This may be done by adding this line to F<.emacs>: +elisp source file F before opening Parrot source files. +See L for instructions. -(load-file "//tools/dev/parrot.el") - -All source files must end with an editor instruction block: +All source files must end with an editor instruction coda: =over 4 =item * C source files, and files largely consisting of C (e.g. yacc, lex, PMC, and -opcode source files), must end with this block: +opcode source files), must end with this coda: /* * Local variables: @@ -299,7 +297,7 @@ =item * -Perl source files must end with this block: +Perl source files must end with this coda: # Local Variables: # mode: cperl
[svn:parrot-pdd] r14452 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:05 2006 New Revision: 14452 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Move pdd07 out of clip Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
[svn:parrot-pdd] r14453 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:18 2006 New Revision: 14453 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
[svn:parrot-pdd] r14454 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:40 2006 New Revision: 14454 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
[svn:parrot-pdd] r14455 - in trunk: . docs/pdds
Author: chip Date: Wed Sep 6 15:57:46 2006 New Revision: 14455 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: About 25% done with update of pdd07. Modified: trunk/docs/pdds/pdd07_codingstd.pod ==
[svn:parrot-pdd] r14840 - in trunk: . docs/pdds/clip
Author: chip Date: Tue Oct 3 12:36:36 2006 New Revision: 14840 Removed: trunk/docs/pdds/clip/pdd07_codingstd.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: Remove redundant pdd07 (closes: #40419)
[svn:parrot-pdd] r15330 - in trunk: . compilers/imcc docs docs/pdds include/parrot src
Author: chip
Date: Fri Nov 10 11:12:20 2006
New Revision: 15330
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
trunk/compilers/imcc/imcc.l
trunk/compilers/imcc/imcc.y
trunk/compilers/imcc/pcc.c
trunk/compilers/imcc/symreg.h
trunk/docs/pcc_state.pod
trunk/include/parrot/enums.h
trunk/include/parrot/op.h
trunk/src/bignum.c
trunk/src/inter_call.c
Log:
Remove the :maybe_flat "feature", which was intended to help Perl 6, but
they never used it.
Substantially improve editorial quality of pdd03 (++particle).
Modified: trunk/docs/pdds/pdd03_calling_conventions.pod
==
--- trunk/docs/pdds/pdd03_calling_conventions.pod (original)
+++ trunk/docs/pdds/pdd03_calling_conventions.pod Fri Nov 10 11:12:20 2006
@@ -59,10 +59,11 @@
"(..., 0x200, flags0, ...)", ..., "name", REG0, ...
The flags string is a literal quoted string denoting a list of zero or more
-comma-separated integers. The list as a whole may be surrounded by
-parentheses. Integers may be specified either in decimal, or if prefixed with
-"0b"/"0x", in binary/hexadecimal. There must be exactly one integer for each
-value or register given.
+comma-separated integers. Integers may be specified either in decimal, or if
+prefixed with "0b"/"0x", in binary/hexadecimal. There must be exactly one
+integer for each value or register given.
+
+(DEPRECATED: The list as a whole may be surrounded by parentheses.)
For documentation purposes we'll number the bits 0 (low) through 30 (high).
Bit 31 (and higher, where available) will not be used.
@@ -109,63 +110,29 @@
The value is a literal constant, not a register. (Don't set this bit
yourself; the assembler will do it.)
-=item 5 C
-
-If this bit is set on a PMC value, then the PMC must be an aggregate or a
-scalar containing a reference to an aggregate. The contents of the aggregate,
-rather than the aggregate itself, will be passed.
-
- If the NAMED bit is also set, the aggregate will be used as a
- hash; its contents, as key/value pairs, will be passed as
- named parameters. The PMC must implement the full hash
- interface. {{ TODO: Limit the required interface. }}
-
- array; its contents will be used as positional parameters.
-
-The meaning of this bit is undefined when applied to integer, number, and
-string values.
-
-=item 6 C
-
-If this bit is set on a PMC value, and:
+=item 5 C (P only)
-=over 4
-
-=item a
+If this bit is set on a PMC value, then the PMC must be an aggregate. The
+contents of the aggregate, rather than the aggregate itself, will be passed.
-the PMC is either an aggregate or a scalar containing a reference to
-an aggregate, and
+If the C bit is also set, the aggregate will be used as a hash; its
+contents, as key/value pairs, will be passed as named parameters. The PMC
+must implement the full hash interface. {{ TODO: Limit the required
+interface. }}
-=item b
-
-the target register has the SLURPY bit set,
-
-=back
-
-then pass the PMC value as a list of values, in these ways:
-
-=over 4
-
-=item a
-
-if the value is an array, pass its elements in the normal way (FLAT
-style);
-
-=item b
-
-if the value is a hash, pass its elements as a list of key/value
-pairs contained in HLL-specific 'pair' PMCs.
-
-=back
+If the C bit is not set, the aggregate will be used as an array; its
+contents will be passed as positional parameters.
The meaning of this bit is undefined when applied to integer, number, and
-string values. It may not be combined with the NAMED bit.
+string values.
+
+=item 6 (unused)
-=item 7 C<(unused)>
+=item 7 (unused)
-=item 8 C<(unused)>
+=item 8 (unused)
-=item 9 C
+=item 9 C (C or string constant only)
When the FLAT bit is also set, behavior is as described above in the "FLAT"
section. Otherwise, this bit may only be set on a unique string constant
@@ -195,9 +162,9 @@
=over 4
-=item 4 C<(unused)>
+=item 4 (unused)
-=item 5 C
+=item 5 C (P only)
If this bit is set on a P register, then it will be populated with an
aggregate that will contain all of the remaining values that have not already
@@ -206,15 +173,13 @@
All such values will be converted to PMCs according to the detailed rules
below, and those PMCs will be stored into the new aggregate.
- If the NAMED bit is also set, the aggregate will be an
- HLL-specific hash type and the contents will be all
- unassigned _named_ parameters.
-
- If the NAMED bit is not set, the aggregate will be an
- HLL-specific array type and the contents will be all
- unassigned positional parameters.
+If the C bit is also set, the aggregate will be the HLL-specific hash
+type and the contents will be all
[svn:parrot-pdd] r15527 - in trunk: . docs/pdds
Author: chip
Date: Tue Nov 14 09:40:26 2006
New Revision: 15527
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Incremental improvement to pdd07 "coding standards":
* Prefer "char *p" to "char* p".
* Prefer that structures have both tags and typedefs.
* Add "Portability" and "Defensive programming" sections.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Nov 14 09:40:26 2006
@@ -145,6 +145,11 @@
=item *
+Pointer types should be written with separation between the star and the base
+type, e.g. C, but not e.g. .
+
+=item *
+
There should be one space between C keywords and following open parentheses,
e.g. C.
@@ -232,9 +237,13 @@
=item *
-All functions must have prototypes in scope at the point of use. Prototypes
-for extern functions must appear only in header files. If static functions
-are defined before use, their definitions serve as prototypes.
+Structure types must have tags.
+
+=item *
+
+Functions must have prototypes in scope at the point of use. Prototypes for
+extern functions must appear only in header files. If static functions are
+defined before use, their definitions serve as prototypes.
=item *
@@ -255,6 +264,14 @@
=item *
+Structure types should have typedefs with the same name as their tags, e.g.:
+
+typedef struct Foo {
+...
+} Foo;
+
+=item *
+
Avoid double negatives, e.g. C<#ifndef NO_FEATURE_FOO>.
=item *
@@ -262,7 +279,7 @@
Do not compare directly against NULL, 0, or FALSE. Instead, write a boolean
test, e.g. C.
-(Note: C values should be checked for nullity with the C
+(Note: C values should be checked for nullity with the C
macro, unfortunately leading to violations of the double-negative rule.)
=item *
@@ -313,6 +330,110 @@
list of typedefs, and parrot.el should read it or contain it. }}
+=head2 Portability
+
+Parrot runs on many, many platforms, and will no doubt be ported to ever more
+bizarre and obscure ones over time. You should never assume an operating
+system, processor architecture, endian-ness, size of standard type, or
+anything else that varies from system to system.
+
+Since most of Parrot's development uses GNU C, you might accidentally depend
+on a GNU feature without noticing. To avoid this, know what features of gcc
+are GNU extensions, and use them only when they're protected by #ifdefs.
+
+
+=head2 Defensive Programming
+
+=head3 Use Parrot data structures instead of C strings and arrays
+
+C arrays, including strings, are very sharp tools without safety guards, and
+Parrot is a large program maintained by many people. Therefore:
+
+Don't use a C when a Parrot STRING would suffice. Don't use a C array
+when a Parrot array PMC would suffice. If do use a C or C array,
+check and recheck your code for even the slightest possibility of buffer
+overflow or memory leak.
+
+Note that efficiency of some low-level operations may be a reason to break
+this rule. Be prepared to justify your choices to a jury of your peers.
+
+=head3 Pass only C to C and C
+
+Pass only values in the range of C (and the special value -1,
+a.k.a. C) to the isxxx() and toxxx() library functions. Passing signed
+characters to these functions is a very common error and leads to incorrect
+behavior at best and crashes at worst. And under most of the compilers Parrot
+targets, C I signed.
+
+=head3 The C keyword on arguments
+
+Use the C keyword as often as possible on pointers. It lets
+the compiler know when you intend to modify the contents of something.
+For example, take this definition:
+
+int strlen(const char *p);
+
+The C qualifier tells the compiler that the argument will not be
+modified. The compiler can then tell you that this is an uninitialized
+variable:
+
+char *p;
+int n = strlen(p);
+
+Without the C, the compiler has to assume that C is
+actually initializing the contents of C.
+
+=head3 The C keyword on variables
+
+If you're declaring a temporary pointer, declare it C, with the
+const to the right of the C<*>, to indicate that the pointer should not
+be modified.
+
+Wango * const w = get_current_wango();
+w->min = 0;
+w->max = 14;
+w->name = "Ted";
+
+This prevents you from modifying C inadvertantly.
+
+new_wango = w++; /* Error */
+
+If you're not going to modify the target of the pointer, put a C
+to the left of the type, as in:
+
+const Wango * const w = get_current_wango();
+if (n < wango->min || n > wango->max) {
+/* do something */
+}
+
+=head3 Localizing variables
+
+Declare variables in the innermost scope possible.
+
+if (foo) {
+int i;
+
Re: Perl Doesn't Suck
Michael G Schwern <[EMAIL PROTECTED]> writes: > On Fri, Jun 29, 2001 at 05:29:53PM -0500, Elaine -HFB- Ashton wrote: > > Not all OS, though most, have Perl in the base install and those that do > > even have problems. Config.pm has issues on HP and Sun, RedHat has spotty > > RPMs that occsaionally go awry. > > That's their fault. Find a better distribution. Or send suggestions on how to make it better. Send them to me if need be. If you want better Red Hat RPMs, send feedback. If you've sent feedback, give me a URL and I'll see what I can do to improve the situation. I've had issues with our mod_perl and apache RPMs, but the perl RPMs are pretty good. Combined with /usr/lib/rpm/cpanflute for turning cpan tarballs into RPMs, it works pretty well, in my experience. I used to compile from scratch, but once I started working with RPM and not against it, I had good success. Chip -- Chip Turner [EMAIL PROTECTED] [EMAIL PROTECTED]
PDD20: An idea: Call frames as PMCs
{ First, let's have a little applause for Leo for implementing the new
lexical scheme in, what, a week? He says it was only a half-day's
work, too. Nice work, dude! }
First some background for those of you who haven't read pdd20:
* Read pdd20.
But if you don't have time:
* LexPads are PMCs that provide a hash-like interface to lexical
variables.
* Each call frame may optionally have a LexPad.
Now, on to the idea:
HLLs need introspection on call frames and their lexicals. I figure
the easiest way to support HLL introspection of call frames is to make
call frames be PMCs. They would have METHODs like:
get_sub()# returns the subroutine being executed
get_lexicals() # returns the LexPad, or Null if none
get_caller() # returns the parent call frame
etc. We'd probably only need one new opcode, if that: something like
$P0 = callframe
to return the current call frame, which could then be walked with
get_caller(). I suppose we could toss it a version that takes an
INTVAL like:
$P0 = callframe 1
to walk up that many frames.
(Also, incidentally, Continuations would have METHOD get_frame().)
Now on to the questions, mostly for Leo:
(1) If this were implemented naively, would it be a significant
slowdown?
(2) How about hacks/cheats to make it fast?
(2a) For example, what if the internal call frame structure remains
its current non-PMC self, and the C opcode actually creates
a _wrapper_ PMC? The only downside to that I could see is that PMC
identity would not callframe identity, and I could live with that if
it kept things fast.
(2b) Or maybe the PMC could be created on demand - only when the user
asks for it - and then cached in the low-level call frame structure,
so that would only need to be created once? This seems like the best
choice, assuming GC issues are manageable.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: PDD20: An idea: Call frames as PMCs
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote: > On Nov 13, 2005, at 4:45, Chip Salzenberg wrote: > > $P0 = callframe 1 > > We already have this kind of introspection: $ grep caller t/pmc/sub.t OK, the Interpreter PMC interface is certainly flexible enough to handle the introspections we need. > OTOH treating a callframe PMC as "normal" PMC would mean that its > contents is kept alive as long as the callframe PMC lives. This would > make timely destruction near to impossible in the case of an existing > callframe PMC. OK, call frame as PMC looks like a non-starter. Consider it rescinded. > [1] I'd use just methods, either on the interpreter or a sub pmc: > > interp."get_caller"(n_levels)# interpreter method or > sub_class = getclass 'Sub' > sub_class."get_caller"(n_levels) # class method 0 = this sub, 1 = > caller, ... > a_sub."get_caller"(nlevels) # obj method, if you already have a sub Well, like I explained WRT lexicals, subroutines don't have callers (nor do they have LexPads). _Call_frames_ have callers (and LexPads). Which leads to: The current introspection model only walks back the current call chain. That's good but not enough. We also need to walk back any live call chain, using any live continuation as a starting point. How about if we implement get_caller() on Interpreter and Continuation, rather than Interpreter and Sub? Alternatively, I guess we could make get_caller() take two parameters: a Continuation as a starting point (Null would mean "me"), and a number of levels up. PS: I generally dislike the road-painting algorithm[*] implied by the "nlevels" interface, but optimizing for introspection is silly, so I'm not going to worry about it. [*] Painting a line in the road but not moving your paint can: 1. paint a meter, walk one meter to the bucket 2. walk one meter, paint a meter, walk two meters to the bucket 3. walk two meters, paint a meter, walk three meters to the bucket etc. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Making parrot portable
On Mon, Nov 14, 2005 at 05:19:49PM +0100, Florian Ragwitz wrote: > After I've collected enough informations I'll start implementing the > necessary changes. I hope it'll be done by the end of this week. I'm not > sure how I should handle that though. I guess it might break parrot > building for a while. So shall I do it in trunk, do a local svk branch > and provide snapshots or bloat the repository some more and create a new > svn branch? If you're doing all your own development and testing, I'd suggest a local svk branch. Providing snapshots is welcome but not mandatory. Once you've experimented enough to know for sure that your changes are an overall improvement (and specifically that they don't break the architectures that work now), you could commit your work to the trunk. Thanks muchly for asking... -- Chip Salzenberg <[EMAIL PROTECTED]>
Call frame introspection (was Re: PDD20 - Call frames as PMCs)
On Tue, Nov 15, 2005 at 10:17:30AM +0100, Leopold Toetsch wrote:
> Autrijus mentioned on #parrot that we'd need weak pointers at some
> time. Then we can reconsider callframe PMCs.
Ah, weak pointers. I remember a time without weak pointers. It was a
happy time. Birds chirped in the trees
> >How about if we implement get_caller() on Interpreter and Continuation,
> >rather than Interpreter and Sub?
>
> ... Interpreter and Sub and Continuation ;-) Dropping the interface
> from Sub would again need to expose the RetContinuation [...]
I certainly agree that exposing the RetContinuation, which
automatically promotes it and its whole call chain to a full
Continuation, is not something to do routinely.
However, it's a Bad Thing to put get_caller() or any other such call
frame introspection query into the Sub interface. You might as well
put a filename() query on a Unix inode.[*] That's gotta go, and it's
gotta not come back.
If caller introspection is common enough that invoking a method on
Interpreter is too slow or inconvenient -- and since we can't use
Continuations as the primary interface for caller queries -- I guess
the next step of optimization would be specialized opcodes for call
frame introspection. I hope we don't have to go there, and we can
stick with the Interpreter interface for common usage.
> > Alternatively, I guess we could make
> >get_caller() take two parameters: a Continuation as a starting point
> >(Null would mean "me"), and a number of levels up.
>
> Hmm. That are 3 params in the method: object, start, level. I guess
> this needs first some thoughts, how we handle class methods, when
> invoked by an instance of the class.
What's bad about how it works now? <- not a rhetorical question
[*] an inode may have as few as zero or as many as USHORT_MAX[**] names,
and finding them all requires scanning a disks's entire directory tree
[**] your mileage may vary
--
Chip Salzenberg <[EMAIL PROTECTED]>
Hashing: avoid MD5 and SHA-1; use SHA-2 or Whirlpool
"I don't know if you guys have been keeping up with current events, but MD5 just got its ass kicked!" - with apologies to Private Hudson It's been known for some time in the crypto world that MD5 is weak, that there are shortcuts to finding hash collisions. Recently, that weakness has turned into a full-fledged failure: It is now possible to quickly and easily craft two very different files with identical MD5 hashes. MD5 is dead. Don't use it. Similarly, we should avoid SHA-1 for any permanent purpose, though in the short term it's not quite dead yet. No one has demonstrated an ability to create SHA-1 collisions on demand (as far as I've heard, anyway), but SHA-1 is "a wounded fish in shark-infested waters"[*], and an MD5-scale failure may be just a matter of time. So what should we use for hashing? Two good choices I know of: * The SHA-2 family (including SHA-256 and other variants) is showing no signs of weakness AFAIK. * Whirlpool [**] seems strong enough too; Bruce Schneier describes it as "a good choice". Ah, crypto is such fun. [*] http://www.networkworld.com/news/2005/110105-nist-crypto.html [**] http://paginas.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Hashing: avoid MD5 and SHA-1; use SHA-2 or Whirlpool
On Wed, Nov 16, 2005 at 12:44:36PM -0800, Chip Salzenberg wrote: > * The SHA-2 family (including SHA-256 and other variants) is showing no >signs of weakness AFAIK. > * Whirlpool [**] seems strong enough too; Bruce Schneier describes it >as "a good choice". Not to make a long discussion of this, but there's also: * RIPEMD160 http://homes.esat.kuleuven.be/~bosselae/ripemd160.html I'm getting the feeling that the real lesson is that any hash header system we build will require pluggable hash algorithms, because anything we pick as strong today may be broken tomorrow (or in ten years). -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: New pmc syntax for HLLs.
On Fri, Nov 18, 2005 at 10:23:24AM -0500, Will Coleda wrote:
> pmclass TclString extends TclObject extends String dynpmc group
> tcl_group hll Tcl maps String { ... }
Nice improvisation on an existing theme. One of these months I'll get
around to making op and pmc definitions less clunky. Meantime, I'm
glad the fix was so straightforward.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #37700] [TODO] Changing Default STDOUT/STDERR Filehandles for PIR Code
On Thu, Nov 17, 2005 at 08:10:59AM -0800, jerry gay wrote: > it seems we're missing an op (freopen) that would make this > possible. we've already got fdopen, getfd, getstdout, getstderr, so > we're mostly there. Sounds more like you want fdreopen. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Fwd: Renaming grep
On Sat, Nov 19, 2005 at 05:46:51AM +0200, Ilmari Vacklin wrote: > I don't much like it - it looks like a mistyped 'shift'. > Is 'filter' too long? I usually avoid P6L discussions, but: GNU Make has "filter" and "filter-out", and I've always found the polarity hard to remember. I like grep. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Hashing: avoid MD5 and SHA-1; use SHA-2 or Whirlpool
On Wed, Nov 16, 2005 at 05:26:05PM -0800, Brent 'Dax' Royal-Gordon wrote: > My understanding is that the best attack on SHA-1 which can find two > plaintexts with the same hash value in 2^63 operations. > [...] > Basically, SHA-1 isn't a problem for us yet, but it's looking weak. OK. Thanks for quantifying that, I'd missed the numbers. > > I'm getting the feeling that the real lesson is that any hash header > > system we build will require pluggable hash algorithms [...] > > From what I've read, that was one of the conclusions of NIST's recent > hash workshop. I think we've been reading the same blog. :-) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd20 and :outer
On Tue, Nov 22, 2005 at 03:28:02PM +0100, Leopold Toetsch wrote:
> Below are two cases of inner subs in Perl5 and Python. The first
> (do_add3) is a plain nested subroutine, which is in the call chain. The
> second (mk_add3) uses a closure. perl5 can't deal with case 1 properly
> and warns.
>
> The question is: should Parrot cover case 1 too with :outer and it's
> default LexPad, or how would the code be translated to PIR?
>
> sub do_add3 {
> my $a = $_[0];
> sub add3 {
> $a + 3;
> }
> add3();
> }
What Perl 5 does with that case is just a plain old bug, or more
precisely, a consequence of how Perl 5 implements capturing a lexical
environment. It's just bad. Don't even try supporting it.
OTOH, that same case in Perl 6 is a normal closure and is supported with
the default LexPad:
.sub do_add3
get_params "(0)", $P0
.lex '$a', $P0
.lex '&add3', $P1
.const .Sub add3 = "add3"
$P1 = newclosure add3
$P1()
.end
.sub add3 :anon :outer(do_add3)
$P0 = fetch_lex '$a'
$P1 = $P0 + 3
.return ($P1)
.end
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd20 and :outer
On Tue, Nov 22, 2005 at 09:32:37AM -0800, Chip Salzenberg wrote:
> $P0 = fetch_lex '$a'
I meant "find_lex", of course.
PS: fetch_*, get_*, find_*, ... so many naming conventions, so little
reason for them.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd20 and :outer
On Tue, Nov 22, 2005 at 09:42:38AM -0800, jerry gay wrote:
> your example in the previous message made me think. what will parrot
> do if a parrot sub declares the :outer subpragma, and the sub to which
> it refers doesn't have a lexical pad?
Nothing; that's entirely legal. And it's even useful, *if* the outer
sub has a :outer of its own.
sub foo ($a) {
my sub bar {
my sub baz { $a }
&baz; #note - this returns a reference
}
bar();
}
While &bar has no pad, it does have :outer(foo), so the find_lex in
&baz will work.
> .sub do_add3
> .const .Sub add3 = "add3"
> $P1 = newclosure add3
> $P1()
> .end
>
> .sub add3 :anon :outer(do_add3)
> .return ($P1)
> .end
>
> compile error? runtime error? warning only, and error on lexical
> access in inner sub?
I'd call this correct but silly, kind of like assigning to a register
that doesn't get used afterwards.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: DynLexPad
On Tue, Nov 22, 2005 at 05:50:39PM +, Roger Browne wrote: > Leopold Toetsch wrote: > > .HLL_map .LexPad -> .DynLexPad # (2) > > Why not use "," instead of "->"? Indeed. We shouldn't introduce "->" at this point, when we already use the perfectly serviceable comma for analogous cases. > I'd prefer to ask for mappings explicitly, e.g. something like this: > >.HLL "Tcl", "tcl_group" >... >$P0 = new Integer # really Integer >$P1 = new_mapped Integer # really TclInteger Hm. Why? -- Chip Salzenberg <[EMAIL PROTECTED]>
Lexical store semantics - Q for Tcl guys
Quick question for Tcl folks. Currently, store_lex is *always* an aliasing operation. That is, after store_lex 'a', $P0 the old PMC that used to be accessible by $P1 = find_lex 'a' is now gone (unless you kept a reference somewhere else). (To modify an existing lexical, the sequence is $P1 = find_lex 'a' followed by some mutating operation on $P1.) Is this a problem for Tcl implementation? If so, how? -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: DynLexPad
On Wed, Nov 23, 2005 at 09:09:00AM -0500, Will Coleda wrote:
> >Why bother with an artifical subclass?
>
> Mainly to avoid having the C code in my .pmc
I'm very much in favor of adding explicit metadata, which is
parseable, rather than just limiting ourselves to writing the
executable consequences of the metadata.
Hm. That was a little opaque. Let me try again. I almost always
prefer a declaration like (e.g.)
foo isa bar
over the executable equivalent such as (e.g.)
foo::class_init { copy_stuff_from('bar') }
You can always generate code from parseable data, but not vice versa.
Of course, if the code is formalized enough, you can treat it as data,
but that way lay either a black hole of hackery or Lisp.
Y'know, it's at times like this I envy the Lisp guys, who pulled off
the greatest scam in programming history: skipping the real language
and getting the programmers to write ASTs.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Subs may not contain dynamic call info, ever (was Re: r10151)
On Wed, Nov 23, 2005 at 03:14:40PM -, [EMAIL PROTECTED] wrote:
> implement Sub.get_caller() method; test
You keep confusing static and dynamic call information.
Like I've said (repeatedly :-)), rule #1 of call info is:
Subs don't have callers.
Call frames have callers.
Therefore, this code is not OK, because the Parrot_sub structure has
information it can't have:
> +METHOD PMC* get_caller() {
> +struct Parrot_sub * sub = PMC_sub(SELF);
> +PMC* cont, *sub_pmc;
> +cont = sub->ctx->current_cont;
> +sub_pmc = PMC_cont(cont)->to_ctx->current_sub;
> +return sub_pmc ? sub_pmc : PMCNULL;
> +}
Parrot_sub must not have a ctx member. Parrot_sub must have no
members which reflect dynamic calls, because with recursion you can
guarantee that there's no one correct answer for any dynamic query on
a Sub. (Continuations just make it worse.)
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Subs may not contain dynamic call info, ever (was Re: r10151)
On Wed, Nov 23, 2005 at 10:49:18PM +0100, Leopold Toetsch wrote: > On Nov 23, 2005, at 19:08, Chip Salzenberg wrote: > >You keep confusing static and dynamic call information. > > Not confusing actually, maybe abusing the static sub structure by > adding a dynamic field 'ctx' - yes. Point taken - the code may be confused, but that doesn't mean you are. :-) But that kind of abuse is just going to end in tears. > Chip: > > Subs don't have callers. > > Call frames have callers. > > And callframes aren't PMCs (because we don't have weak pointers) > therefore an introspection of :outer can only return the 'Sub' of outer > but not actually the real call frame aka the context ... > > The introspection $frame.get_lexpad (pdd20) can't be implemented w/o > that currently. Thanks for the reminder, I'd forgotten to put that IRC discussion into the doc. I just committed r10202, which includes: +For example, to get the immediate caller's LexPad, use: + +$P0 = getinterp +$P1 = $P0["lexpad"; 1] -- Chip Salzenberg <[EMAIL PROTECTED]>
Ideas on :outer and closures
On Wed, Nov 23, 2005 at 10:49:18PM +0100, Leopold Toetsch wrote:
> outer_sub - (the static sub PMC info) can't refer to :outer because the
> :outer can be a closure too. There are many incarnations of the :outer
> then. Therefore the implementation needs sub->ctx (currently and IMHO).
The docs conflate non-closure Subs and closure Subs in confusing way.
Sorry. So I'm going to write my way through this. I think the design
as is can work, with each Sub having a static outer_sub attribute, but
only if closures also have an attribute that points to the Sub that
they were created from.
(Perl 5 calls this closure-creation process "cloning". I might adopt
it, even though the reasons for the name are obsolete. I kept the
term "pad" even though it's also technically obsolete...)
OK, here goes. Correct me where I go wrong:
* The initial static result of compilation is N Parrot_subroutines
(Subs).
* Each of these Subs may have a non-NULL outer_sub attribute, which
describes the textual relationship of the Subs in the original
source code. For example, given:
sub foo {
my sub bar {
my sub baz {
}
}
}
baz.outer_sub is bar, and bar.outer_sub is foo.
* This is a static description of a static situation (the source code
doesn't evolve at runtime). So it need never change.
* The result of newclosure is a new Sub, but I'm going to call it a
Closure for clarity in this message.
Now speculation:
* We are free to give the Closure a new outer_sub attribute at the
time it's created, if we choose, and that won't violate the rule
that the original (source) Sub's attributes should be const, as
long as the old outer_sub value can be captured.
* For a nested closure like &baz above, how about if at newclosure
time, we set the outer_sub to the specific Closure of bar that is
currently executing?
In order to do this:
* Closures would need an attribute that points to the Sub they were
created from. That would allow us to connect the running &bar
_Closure_ to the &bar _Sub_ it was created from. (The reason we
would need that connection is that the Sub &baz's outer_sub
attribute points only to the static Sub &bar.)
OK so far?
If so I'll follow up with design docs.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Ideas on :outer and closures - 2nd try
Well, I had the right idea, but at a key moment I zigged when
I should have zagged. So let's try this again.
On Wed, Nov 23, 2005 at 10:49:18PM +0100, Leopold Toetsch wrote:
> outer_sub - (the static sub PMC info) can't refer to :outer because the
> :outer can be a closure too. There are many incarnations of the :outer
> then. Therefore the implementation needs sub->ctx (currently and IMHO).
The docs accidentally conflate non-closure Subs and closure Subs. So
I'm going to write my way through this. I think the design as is can
work, with each Sub having a static outer_sub attribute, but only if
closures also have an attribute that points to the Sub that they were
created from.
(Perl 5 calls this closure-creation process "cloning". I'll adopt
that term for this doc, and maybe permanently.)
OK, here goes. Correct me where I go wrong:
* The initial static result of compilation is N Parrot_subroutines
(Subs).
* Each of these Subs may have a non-NULL outer_sub attribute, which
describes the textual relationship of the Subs in the original
source code. For example, given:
sub foo {
my sub bar {
my sub baz {
}
}
}
baz.outer_sub is bar, and bar.outer_sub is foo.
* This is a static description of a static situation (the source code
doesn't evolve at runtime). So it need never change.
* The result of newclosure is a new Sub, but I'm going to call it a
Closure for clarity in this message.
* Each Closure has an "outer_ctx" attribute, which points to the
call frame in which it was cloned. That call frame contains a
pointer to the Sub (or Closure) that cloned the leaf Closure.
* Therefore, we have outer_sub for the relationship of non-Closure
Subs, and caller_ctx for Closure (cloning) relationships.
* And thus there should be no need to modify a Sub after compilation,
nor a Closure after cloning.
Does this describe the current situation and its features?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Subs may not contain dynamic call info, ever (was Re: r10151)
On Thu, Nov 24, 2005 at 08:54:54AM +0100, Leopold Toetsch wrote:
> On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
> >You keep confusing static and dynamic call information.
>
> While at static objects like subroutine PMCs - there is some code
> around that is setting properties on .Sub objects.
Just to be clear, I don't think setting properties on a Sub is
necessarily a bad thing. Let's say a user wants to create a bunch of
Subs and then set properties on them for some design reason, say for
the purpose of categorization or debugging or some such. That's fine
with me. I'm only concerned (at the moment :-)) about Parrot itself
storing dynamic (call-stack-dependent) state inside Sub objects.
BTW, this principle still applies to Closures, but in a non-obvious
way. Once Closures are cloned they can be called recursively, so call
stack info about _them_ being called still can't be stored in them.
Granted, they have attributes like "outer_ctx" (now) or "lex_env"
(someday). But those are actually metadata relating to the single
moment of the creation of the Closure: once the Closure is created,
they never change. So they're still really const attributes.
> $ find . -name '*.imc' -o -name '*.pir' | xargs grep -w setprop
Whole bunch of 'em, yup.
> At least one in runtime/parrot/library/Stream/Writer.imc is bogus if
> not illegal:
>
> .const .Sub stub = "_reader_stub"
> setprop stub, "CALL", source
>
That is surely a bug. It's non-reentrant at the very least.
I'd have to learn more about the Stream library to suggest a good fix.
A lame fix might be a static Hash that uses something stream-specific
as a key and the "CALL" attribute that would otherwise have been set on
those Subs as a value. Or maybe a property on the stream? (I'm just
guessing that there is such a thing as a stream PMC.)
> See also src/packfile.c:3200 and :377. The latter ('mark_1_seg') is run
> from GC to keep PMC 'constants' alive and I really don't like this. If
> PMC constants are created in the constant PMC pool, DOD-marking isn't
> needed anymore.
(Those line numbers don't match any more btw - if you want to write more
about it please update them)
The comment on mark_1_seg says that manually marking const PMCs is a
consequence of non-const-created properties. I think that's valid.
Granted, I don't like the idea of
3.14159 but hexagonal # [*]
and I hope nobody writes that. But the case of adding new properties to
compiled Subs seems valid.
[*] Old joke about Illinois (?) legislator who attempted to declare
that, officially, pi == 3. Consequences to all circles in the
state should be obvious. :-,
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #37760] [TODO] imcc - item lists (a C job)
On Fri, Nov 25, 2005 at 04:25:03AM -0800, Leopold Toetsch wrote: > There are about 10 such lists around, which could be unified easily. The > current code is suboptimal anyway, because resizing is done by 1 mostly. > Some of the lists allocate ptr space and items, which can also be > simplified and reduces indirection by one. > > Therefore the job would be to replace *gradually* all these lists by a > common interface. I heartily endorse this product and/or service. There exist tricks for making the macros in such a way that one node can be on *multiple* lists. Mostly they consist of having multiple low-level nodes structures in a single high-level node, then doing pointer arithmetic with offsetof() to move from the base of the high-level node to/from the base of the low-level node(s). That's something I would very much like to see. (Damn, sometimes I really do wish for C++ again. This is such a template thing.) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: exception handlers & calling conventions
On Fri, Nov 25, 2005 at 11:45:40PM +0100, Leopold Toetsch wrote: > Technically an excpetion is kind of an object with some info (TODO) and > the exception handler is a (limited) continuation: > > pmclass Exception_Handler extends Continuation ... # see classes/ Neat. > catch_label: > get_results "(...)", Pexcept, Smessage, ... # whatever Right. > And the opcode >push_eh catch_label > is creating the Exception_handler with the 'get_results' in it's > context, so that it can deliver results. Ah, interesting! And definitely a great way to implement the current scheme. I have some thoughts about changing the current scheme, which I'll mention in another message. Nothing impending, though. > Detailed syntax bits welcome ... Let's see... # (a) catch_label: .results ($P0) Not bad. Matches up with get_results. But the direction isn't entirely clear when you read it: Is it setting or getting results? # (b) catch_label: .get_results ($P0) Better, I think. # (c) catch_label: ($P0) = @EXCEPTION # or some other magic word Ew. I still like (b). -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: PDD20, Tcl
On Mon, Nov 28, 2005 at 01:16:49PM -0500, Will Coleda wrote: > With patches from myself (to tcl) and leo (to parrot), partcl is once > again passing 100% of the tests, using PDD20. Yay! > The biggest hurdle was having some arbitrary (non :lex-ified) parrot > sub issue our find_lex and store_lex for us to ease transition. As > more of tcl becomes compiled, we can probably eliminate this code > path entirely, but that's a ways off. Yow. The below code looks a bunch like what the find_lex opcode is supposed to do. What made it necessary? > .sub find_lex_pdd20 > .param string variable_name > > .local pmc interp, lexpad, variable > .local int depth > interp = getinterp > depth = 2 # we know it's not us or our direct caller. > > get_lexpad: > # Is there a lexpad at this depth? > lexpad = interp["lexpad";depth] > unless_null lexpad, got_lexpad > > # try again > inc depth > goto get_lexpad > got_lexpad: > variable = lexpad[variable_name] > .return(variable) > .end > > -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: PDD20, Tcl
On Mon, Nov 28, 2005 at 03:22:10PM -0500, Will Coleda wrote: > Tcl variables can be either globals or lexicals (inside a [proc]). > So, all the code to get a PMC from a varname was factored out to a > single routine that returns the right PMC (global or lexical) > depending on call level. I think I understand: You're creating a subroutine to manipulate a pad, and the subroutine is a common utility which can't specify :outer for all its callers, and find_lex only follows :outer. So you have to use interpreter introspection to find the pad. > > >>.sub find_lex_pdd20 > >> .param string variable_name > >> > >> .local pmc interp, lexpad, variable > >> .local int depth > >> interp = getinterp > >> depth = 2 # we know it's not us or our direct caller. > >> > >>get_lexpad: > >> # Is there a lexpad at this depth? > >> lexpad = interp["lexpad";depth] > >> unless_null lexpad, got_lexpad > >> > >> # try again > >> inc depth > >> goto get_lexpad > >>got_lexpad: > >> variable = lexpad[variable_name] > >> .return(variable) > >>.end > So: This subroutine's loop is technically unnecessary, but convenient: The depth of your utility subroutine from the user-written subroutine with :lex is knowable at compile time, so you could rewrite the function to take a depth parameter and just grab the right LexPad on the first try. But you find it more convenient to loop up the call stack rather than have to calculate the depth everywhere. (Right?) Also: If it weren't for the fact you want to search lexicals and globals every time, you could just use find_lex. Therefore: Something along the lines of find_var could help you. PS: I'd forgotten the lex opcodes used to follow the *call stack*. My unholy $DEITY, they were even more broken than I remembered. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: parrot directory reorganization
On Mon, Nov 28, 2005 at 04:45:33PM -0800, jerry gay wrote: > i propose reorganizing the tree to improve clarity and cohesion. Reorganization would be good at this point, but should be undertaken cautiously so as to minimize unpleasantness. * I can't find a rationale for putting both 'imcc' and 'compilers' at the top level. (Though I see a note that you intended imcc to be under compilers; if so, I think that's good.) * Should pasm be considered a compiler for source organization purposes? I suppose in theory it should: There's more than one assembler syntax for most CPUs. And AFAICT, the actual pasm implementation is intermixed with the PIR implementation, so if imcc goes into compilers, it'll take pasm with it. * The directory name 'src' is a bit fuzzy to me, if 'imcc' and 'compilers' aren't part of it. Perhaps 'vm' for the core machine...? That would include infrastructure PMCs. Lots more interesting ideas, I hope. (Jerry's diagrams follow.) > here is an annotated picture of the current tree (extra info > ped as shown.) > > . trunk > +---ast > +---blib > | +---lib > +---build_tools # move to tools/build/ > +---charset # move to src/charset/ > +---classes # move to src/classes/ > +---compilers > | +---pge > | | +---PGE > | +---tge > | +---TGE > +---config > > +---debian > +---docs > > +---dynclasses# move to src/dynclasses/ > +---dynoplibs # move to src/dynoplibs/ > +---editor# move to tools/editor/, get rid of > Makefile, convert it to perl > +---encodings # move to src/encodings/ > +---examples > > +---imcc > | +---docs > | +---examples > | +---t # move to t/compilers/imcc/ > > +---include > | +---parrot > | +---oplib > +---io# move to src/io/ > +---jit # move to src/jit/ > > +---languages > > +---LICENSES > +---ops # move to src/ops/ > +---pf# move to src/packfile/ > +---runtime > > +---src > +---t > | +---compilers > | | +---pge > | | | +---p5regexp > | | | +---p6rules > | | +---tge > | +---doc > | +---dynclass > | +---examples > | +---library > | +---native_pbc > | +---op > | +---perl > | +---pmc > | +---run > | +---src > | +---stress > | +---tools > +---tools > | +---dev > | +---docs > +---types # move to src/types/ > +---util # move to tools/util/ > > > below is the modified tree, which groups related directories, > and reduces the number of top-level directories from 28 to 15. > > > . trunk > +---ast > +---blib > | +---lib > +---compilers > | +---pge > | | +---PGE > | +---tge > | +---TGE > +---config > | > +---debian > +---docs > > +---examples > | > +---imcc > | +---docs > | +---examples > +---include > | +---parrot > | +---oplib > +---languages > | > +---LICENSES > +---runtime > | > +---src > | +---charset # moved from charset/ > | +---classes # moved from classes/ > | +---dynclasses# moved from dynclasses/ > | +---dynoplibs # moved from dynoplibs/ > | +---encodings # moved from encodings/ > | +---io# moved from io/ > | +---jit # moved from jit/ > | | > | +---ops # moved from ops/ > | +---pf# moved from pf/ > | +---types # moved from types/ > +---t > | +---compilers > | | +---imcc # moved from imcc/t/ > | | | > | | +---pge > | | | +---p5regexp > | | | +---p6rules > | | +---tge > | +---doc > | +---dynclass > | +---examples > | +---library > | +---native_pbc > | +---op > | +---perl > | +---pmc > | +---run > | +---src > | +---stress > | +---tools > +---tools > | +---build_tools # moved from build/ > | +---dev > | +---docs > | +---editor # moved from editor/, no Makefile, > converted to perl > | +---util # moved from util/ > > > this work can and should be done one piece at a time to prevent > widespread panic. if this proposal is accepted, i will create > todo tasks for each unit of work. then, they can be assigned one > at a time, until the task is complete. of course, a realclean / > configure / make test cycle should be done after each change to > ensure it has gone smoothly. > > thoughts? > ~jerry > -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: parrot directory reorganization
On Mon, Nov 28, 2005 at 05:37:19PM -1000, Joshua Hoblitt wrote: > On Mon, Nov 28, 2005 at 04:45:33PM -0800, jerry gay wrote: > > * the editor/ directory contains files for text editors and has > > a generated makefile. there is no reason for this to be a make > > target. a perl script should be created to replace makefile, > > and the dir moved with the other tool & utility scripts. > > I disagree. A Perl script won't do any better of a job and will be more > complex then that rather simple makefile. I mildly agree with Joshua about Makefiles. More to the point, I don't like changing directory tree and build tech at the same time. They're separate changes. > > * imcc test files are not grouped with other tests (this is > > already on my TODO list and should be done RSN.) > > Does it make sense for the tests to even refer to imcc? IMHO Parrot > ability to digest PIR is whats really being tested. However unlikely, > it's worth keeping in ind that Parrots internal PIR compiler may be > replaced someday. Oh, one other thing for the renaming game: IMC vs. PIR Two names enter One name leaves /me giggles -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: exception handlers & calling conventions
On Tue, Nov 29, 2005 at 04:26:09PM +0100, Leopold Toetsch wrote: > Coke: > >If so, why do we specify S0 here?) > > Just for convenience. I appreciate the convenience argument, but given the ease of keyed access, $P0[0] is pretty darned convenient already. And someday we may want to pass things that are more than convenience. So I'd like the signature of exceptions to just be (P), at least for now. Which gives me an idea for PDD03: "IGNORE". Currently there's no way to do the old Perl 5 thing of knowing that the caller passed more than N arguments but you really only want N. How about: exception: .local pmc except .param except .param $P0 :slurp :ignore# don't bother constructing Array if_null $P0, always # it's always Null Hm. Seems like a pretty ugly kludge for a rare case. -- Chip Salzenberg <[EMAIL PROTECTED]>
Solving '=' confusion: ':=' for aliasing
Consider: P0 = P1 P0 = S1 P0 = I1 P0 = N1 o/~ One of these things is not like the others One of these things just doesn't belong o/~ And if I have to read: P0 = new .Integer P0 = 1 one more time... *sigh* Therefore, I propose requiring people to spell aliasing as ':='. This will affect all code generated to use P and S registers. It should be an easy fix (albeit an extensive one). And if we don't do it now, it'll just get harder. So here's the lowdown: P0 := P1 # aliasing: P0 and P1 point to same PMC P0 := opcode # aliasing: P0 points to PMC returned by opcode P0 = ... # assignment: modifies P0, NO MATTER WHAT '...' IS S0 := S1 # aliasing: S0 and S1 point to same header S0 := opcode # aliasing: S0 points to header returned by opcode S0 = ... # assignment: modifies S0, NO MATTER WHAT '...' IS I0 := ... # ILLEGAL I0 = ... # assignment: modifies I0 N0 := ... # ILLEGAL N0 = ... # assignment: modifies N0 Comments? Fresh or rotten vegetables? -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote: > Chip Salzenberg <[EMAIL PROTECTED]> wrote: > >P0 := P1 # aliasing: P0 and P1 point to same PMC > >P0 := opcode # aliasing: P0 points to PMC returned by opcode > >P0 = ... # assignment: modifies P0, NO MATTER WHAT '...' IS > > > >S0 := S1 # aliasing: S0 and S1 point to same header > >S0 := opcode # aliasing: S0 points to header returned by opcode > >S0 = ... # assignment: modifies S0, NO MATTER WHAT '...' IS > > > >I0 := ... # ILLEGAL > >I0 = ... # assignment: modifies I0 > > > >N0 := ... # ILLEGAL > >N0 = ... # assignment: modifies N0 > > I'm not sure about the last two (in a lot of ways, they're more like > := than = ), I don't see that. The key semantic behind := is alias creation. After I0 = I1 # both old and new syntax is I0 an alias for I1? No. Does modifying I0 modify I1? No. Therefore, that's an '=', not a ':='. Meanwhile, after P0 = P1 # OLD SYNTAX changes to P0 are visible through P1. Thereofore, in the new scheme, that's a ':='. > I suppose that copying looks like: > S0 := copy S1 Yes, modulo the choice of the word "copy". I might call it "clone", which emphasizes that the return value has its own identity. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote: > On Tue, Nov 29, 2005 at 12:08:01PM -0800, Chip Salzenberg wrote: > >P0 := P1 # aliasing: P0 and P1 point to same PMC > >P0 := opcode # aliasing: P0 points to PMC returned by opcode > >P0 = ... # assignment: modifies P0, NO MATTER WHAT '...' IS > > > >S0 := S1 # aliasing: S0 and S1 point to same header > >S0 := opcode # aliasing: S0 points to header returned by opcode > >S0 = ... # assignment: modifies S0, NO MATTER WHAT '...' IS > > First comment: How do we coordinate the transition? Do we go to > having a separate branch (ick), or do we just declare a date in > which the grand renaming will take place? I'm planning a flag day sometime in December. I'm also planning to create a simple "handles most cases" translator. > Second comment: how about access to keyed items -- does this mean: > > P0 := P1[S1] # alias > S0 = P1[S1]# assignment > I0 = P1[S1]# assignment > N0 = P1[S1]# assignment Yes. > P0 = P1[S1]# supported? Yes, it means to fetch a PMC and make P0 an alias to it. Perl 6 equivalent should be, more or less: $a := $array[$i]; > S0 := P1[S1] # presumably an error? Yes, as long as fetch operations can only return PMCs. Given the existence of a generic fetch operation that actually returned a Parrot string value natively, that line could become legal. (Strings _are_ problematic in that they're create automatically in some cases, AFAICT. More on that later.) > Perhaps I've just trained myself to the current implementation, but > I like that the shorter '=' does what I tend to want/expect and I > write an explicit 'assign' or 'set' opcode when I need something > different. The current system does have its advantages, granted. But I think having such a fundamental operator as '=' mean two subtly different things based on visually indistinct clues is just not releasable. And if you can get used to what we have, you'll certainly get used to something better. :-) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 03:25:13PM -0500, Matt Diephouse wrote: > Chip Salzenberg <[EMAIL PROTECTED]> wrote: > > Therefore, I propose requiring people to spell aliasing as ':='. > > "And the Lord did grin. And the people did feast upon the lambs and > sloths, and carp and anchovies, and orangutans and breakfast cereals, > and fruit-bats and large chu..." Skip ahead, Father. > > So here's the lowdown: > > > >P0 := P1 # aliasing: P0 and P1 point to same PMC > >P0 := opcode # aliasing: P0 points to PMC returned by opcode > >P0 = ... # assignment: modifies P0, NO MATTER WHAT '...' IS > > Does that mean that `P0 = ...` is the same thing as `assign P0, ...`? Yup. (BTW, I could imagine that access to assignment via the named 'assign' opcode could go away. But there's no need, really.) > Or, perhaps more accurately, `P1 := ...\n assign P0, P1`? No, PIR doesn't do that kind of thing (allocating P registers) behind your back. If a sequence needs a second P register, PIR will make you name it. Somewhere. Otherwise you'd be unable to e.g. control object lifetime by nulling the register. (Right, Leo?) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 12:36:03PM -0800, Chip Salzenberg wrote: > On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote: > > P0 = P1[S1]# supported? > > Yes, it means to fetch a PMC and make P0 an alias to it. Perl 6 > equivalent should be, more or less: > > $a := $array[$i]; Oops! I conflated old and new. Let me try again. What used to be "P0 = P1[S1]" will be spelled "P0 := P1[S1]". The syntax "P0 = P1[S1]" will no longer be legal. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 12:38:55PM -0800, Brent 'Dax' Royal-Gordon wrote: > Chip Salzenberg <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote: > > > I'm not sure about the last two (in a lot of ways, they're more like > > > := than = ), > > > > I don't see that. > > Well, for one thing, my way would mean that `set` is always `:=`. Oh, that reminds me: I don't mind keeping "set", but I wonder if it's actually _worth_ keeping. > Basically, though, my way would mean that copying the register's exact > contents would always be done with `:=`, and more complicated > assignments with potentially complex semantics would always be `=`. I see your point. But I think awareness of reference semantics is more important. That is, it's more important that a scan of the code for ':=' will show where aliasing might change, leaving '=' to always follow value semantics. There's a bit of semantic spillover from Perl 6 in this view, I'll grant you. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 03:55:22PM -0500, Bob Rogers wrote: > So "aliasing" copies the pointer (i.e. the object itself), and > "assignment" copies the value? Right. Note, however, that you have to *have* a pointer for "copying the pointer" to be meaningful. Thus, since I and N registers are not pointers, they can't support the semantics implied by := . -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 04:27:28PM -0500, Matt Diephouse wrote: > Chip Salzenberg <[EMAIL PROTECTED]> wrote: > > On Tue, Nov 29, 2005 at 03:25:13PM -0500, Matt Diephouse wrote: > > > Or, perhaps more accurately, `P1 := ...\n assign P0, P1`? > > > > No, PIR doesn't do that kind of thing (allocating P registers) behind > > your back. If a sequence needs a second P register, PIR will make you > > name it. Somewhere. Otherwise you'd be unable to e.g. control object > > lifetime by nulling the register. (Right, Leo?) > > That would mean that `P0 = opcode P2` is illegal, right? Depends on the signature of the opcode. If the opcode's first parameter is marked 'out', so the opcode actually modifies the P register to point to a new PMC, ':=' would indeed be required. However, there are also opcodes that set a new *value* for the PMC referenced by their first parameter, but do not modify the register itself. (I believe 'assign' fits that description.) So, if we follow that algorithm, I think these should all be equivalent: assign P0, P1 P0 = assign P1 P0 = P1 The final plan should include more metadata on opcodes. Right now the compiler can distinguish aliasing from non-aliasing, but it also should be able to distinguish "use value for reading" and "use value for writing". Two modes (in and out) are not enough to describe three use cases (require "=", require ":=", and forbid both). -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 11:13:05PM +0100, Leopold Toetsch wrote: > On Nov 29, 2005, at 21:36, Chip Salzenberg wrote: > >I'm planning a flag day sometime in December. I'm also planning to > >create a simple "handles most cases" translator. > > That's all ok with me, but not without an automatic translator [...] Excellent. Now if only I knew a good language for text filters... -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 05:17:25PM -0500, Matt Fowles wrote: > I very much like it. I think I may have suggested something like it > earlier (although I might have only thought it). It's entirely possible. Great minds think alike ... and us too, apparently. :-) > "Computer Science is merely the post-Turing Decline of Formal Systems Theory." But how can you STKO[*] with an infinite tape? [*] Stretch Tape and Kill Operator -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 10:45:12PM +, Roger Browne wrote: > On Tue, 2005-11-29 at 12:08 -0800, Chip Salzenberg wrote: > > Therefore, I propose requiring people to spell aliasing as ':='. > > Is some different symbol possible, to avoid confusing people who use > Algol-like languages where ":=" means assignment (Amber, Ada, Eiffel, > Delphi...)? You've apparently never seen Damian's talk about stupid language tricks. I have. So I know that any language using ":=" for assignment is doomed to obscurity.[*] It's a law of nature. The clinching reason is that the largest crossover populations of PIR programmers will know C, Perl, Python, Ruby, and/or sh, with a smattering of C++. Those languages all use '=' for assignment. And PIR has also historically used '=' for assignment; it's just been inconsistent about the precise target (register vs. PMC). >"=>" for aliasing (looks like something pointing to something else), And that symbol has a really strong semantic history as a pair creation operator in Perl. If it were nonetheless forced to become some kind of modification operator, it looks like it would be modifying the thing on the right (Ah, language design. :-)) [*] Remember, 'obscure' does not mean 'bad' or 'dead'. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Tue, Nov 29, 2005 at 05:51:42PM -0500, Bob Rogers wrote: >I think of PMCs as being objects, not containers for something else, > and ":=" as meaning "copy the object" (which is synonymous with "copy > the reference to the object") and "=" as "copy the contents." Under > this interpretation, both are reasonable for numbers. You're looking at it backwards. P and S registers can do something that I and N registers can't do: They can both point to a common value, so that a change made via one becomes visible via another. In other words, aliasing. I and N registers cannot alias. And aliasing is getting its own operator. -- Chip Salzenberg <[EMAIL PROTECTED]>
pdd03 (calling conventions) revised; get_params vs. READONLY
I've reviewed pdd03 and brought it back from pdds/clip. Mostly it's the same as before, albeit with clarifications and a few flag bits renamed to match PIR. I have made a couple actual changes, though. On the small side, there's a barest hint of named parameters. Most importantly, I've proposed (but not mandated) a get_params flag called "READONLY", which automatically creates a read-only wrapper around a PMC parameter. The primary use case is Perl 6's default argument mode; without some native code support for readonly alias creation, I think it'll be too slow to be practical. On the other hand, Perl 6 may be the only language that has these specific semantics, so Parrot should perhaps butt out. On the gripping hand, Perl 6 could always invent a customized "readonly" opcode to do what it wants before we put it into the base Parrot calling convention, so it may not be necessary to do this yet. Autrijus, what do you think about READONLY aliasing in get_params vs. outline pbc? Is core support premature? -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd03 and Overflow/Underflow - r10269
On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote: > Parrot didn't throw exceptions on param or result count mismatch > until now, and still doesn't. [1] > [1] all PGE and PGE-based stuff is failing, when both are turned on Exceptions should still be the default, even if PGE needs some changes. I agree with you that it should be possible to avoid throwing exceptions, but the error bits aren't the way: they're dynamic, which makes it difficult for compilers to reliably set parameter exception policy. Allowing too few parameters is already possible through the extensive use of :optional. As for the too-many case: If we add a :last flag which means "any additional incoming values should be ignored", then that's covered too. Then users can avoid throwing exceptions in all cases, if that's what they want. Patrick, would that work for you? For that matter, did you know that your code dies when parameter counts are enforced? -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Wed, Nov 30, 2005 at 12:49:13PM -0500, Joshua Juran wrote: > On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote: > >Excellent. Now if only I knew a good language for text filters... > > How about sed or awk? Hm. If only we had a pir2xml, I could use XSLT. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd03 and Overflow/Underflow - r10269
On Wed, Nov 30, 2005 at 03:27:52PM -0500, Will Coleda wrote: > On Nov 30, 2005, at 2:50 PM, Patrick R. Michaud wrote: > >Thus, we really ought to have a way to indicate that a rule (parrot > >sub) can still be safely run even if called with more parameters > >than it expects. > > Isn't this what :slurpy is for? Well, :slurpy is good if you do (or might) want to examine the extra parameters. If you just want to throw them away, there should be a way to say that. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Solving '=' confusion: ':=' for aliasing
On Wed, Nov 30, 2005 at 12:41:59PM -0800, Larry Wall wrote: > private="REFCOUNTED" > refcnt="1"> > > > > > > > > [...] > > Hope this helps I sense a great evil. An evil that has been in abeyance since the defeat of IP over XML-RPC. That is not dead which can eternal lie And with strange aeons, even XML may die -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd03 and Overflow/Underflow - r10269
On Wed, Nov 30, 2005 at 02:39:58PM -0600, Patrick R. Michaud wrote: > At any rate, I found and fixed the two PGE subs that weren't declaring > their (unused) parameters. All p6rules tests now appear to pass in > r10278 with .PARROT_ERRORS_PARAM_COUNT_FLAG enabled. Excellent. Leo, would you be so kind as to rescind the parameter passing error flags, and make mismatches always throw? Unless/until we have :last, users can use :slurpy on an unused register to mean "extra params OK". -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd03 and Overflow/Underflow - r10269
Say, I just noticed this: On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote: >.sub foo > push_eh handler > get_params '(0)', $P0# no .params yet - sorry I remember at one point that get_params had to be the first opcode in the sub. I didn't like that, but I didn't know you'd fixed it. Are there any remaining limitations on the placement of the pdd03 opcodes? -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd20 questions
On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote: > I have some clarification questions about the new pdd20 on lexical > variables -- likely stemming from my having been out of it for so > long. Also I am happy to send a patch to pdd20 capturing these > clarifications once I am sure I understand things correctly. Hey, so this is doubly useful. :-) > 1. What is expected to be in P0 in: >.lex "$a", P0 The ".lex" directive is compile-time only, and has no runtime effect on the contents of P0. (Of course, once a register is available with a lexical name, "store_lex" may modify it.) > 2. Should we provide a way for a compiler to provide depths to the > find_lex and store_lex ops if it chooses to? Maximum depths, you mean? I know of no use case for it. > 3. 'Call frame' is mentioned often--what is a call frame in the > context of continuation passing style? I think "activation record" is the usual term of art. If that's right, and now that I just remembered it (!), I'd welcome a patch that fixes the terminology. > 4. In the section "Closure creation: Capturing the lexical > environment", LexPad is used a couple of times when LexEnv is meant, > right? Fixed. Also, while I was at it, I think I fixed nested closures. At least, I fixed the spec for them. :-) > 5. Thinking about closure support vs. outer support - the difference > and the need for both mechanisms is not clear to me. Could you unpack this, please? > 6. The pdd mentions walking the call stack to find frames ... but is > there a call stack? I call it that mostly for historical reasons. From any given starting point, the records form a singly-linked acyclic list. The overall set of activation records is a tree, with child nodes pointing to parents. > And finding lexpads on the call stack makes me think of dynamic > variable binding rather than lexical? Well, only call frames that belong to textually enclosing subroutines are considered. The old lexical system ignored textual enclosure, which made it broken in all the ways you might think. > 7. Finally, what is the status of the implementation? AFAIK, it all works from the user point of view, except that there are no LexEnv objects per se. Leo has written the pdd20 closure support in a way that keeps more live data than the LexEnv approach. Closures thus use more memory than necessary, but as a result, they may be a lot faster to create. I need to evaluate this to decide whether it (1) works in a way I can live with and (2) even if it does, if the memory issues mean that it needs to be replaced with a real LexEnv. > (As an aside is there interest in having the names of the invoke ops > more consistent, say: callcc and callcc_method; or invokecc and > invokecc_method?) I'm not planning to rename any opcodes ATM. As Allison correctly observes, PIR is an assembly language, not an HLL. So the barrier to cosmetic cleanups is higher. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd20 questions
On Wed, Nov 30, 2005 at 03:58:28PM -0800, Jonathan Sillito wrote: > On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote: > > > 2. Should we provide a way for a compiler to provide depths to the > > > find_lex and store_lex ops if it chooses to? > > > > Maximum depths, you mean? I know of no use case for it. > > Not maximum depth but the exact depth for a given lexical variable in > the case of closures. Ah. Well, there is already supposed to be a variant on find_lex that takes a starting depth, and in the closure-efficiency case the starting depth will always be the final depth, so that use case is taken care of (or will be, once two-arg find_lex is available). > > > 5. Thinking about closure support vs. outer support - the difference > > > and the need for both mechanisms is not clear to me. > > > > Could you unpack this, please? > > Well, using :outer allows the look up algorithm to walk through > enclosing lexical scopes ($sub = $sub.outer). In the case of closures > the LexEnv is populated with the enclosing LexPads which I assume come > from enclosing lexical scopes, which allows the the look up to do the > same thing, no? I must be missing something here. What you're missing is that without the :outer information, Parrot wouldn't be able to decide *which* LexPads *should* be searched, either now (find_lex w/o LexEnv) or later (newclosure -> LexEnv). -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd03 (calling conventions) revised; get_params vs. READONLY
On Wed, Nov 30, 2005 at 10:57:26AM -0800, Jonathan Sillito wrote: > What is the status of the todo's mentioned in the BUGS section, who > is working on these -- I am looking for a place to jump in. Also > what is the status of the exception subsystem you mentioned? All those TODOs are for design, which is hard to delegate. > I guess one more todo I could take on is the add the use of the > set_* and get_* ops to examples/subs. A short example in the pdd > might be helpful too. Examples are very welcome. Just make sure to mark all direct usage of the get/set calling convention opcodes as being not for human consumption. PIR macros like .param are the way to go. "PIR is for humans. Pasm is for silicon-based life forms." - me -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd03 and Overflow/Underflow - r10269
On Thu, Dec 01, 2005 at 01:45:49AM +0100, Leopold Toetsch wrote: > While strict argument checking is and was always in the pdd03, it was > not enforced and is only checkable since today. Therefore I'd like to > keep current settings until after the release. Works for me. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: CREDITS where credit is due
On Sat, Dec 10, 2005 at 05:39:14PM -1000, Joshua Hoblitt wrote: > I'd like to propose that we change submissions.pod to ask that patch > submissions (at least from those without CI rights) include a new or > updated CREDITS entries with them. A pointer to CREDITS would be a good thing; just include a note about its not being mandatory. If I were a new contributor and I submitted a spelling patch, I wouldn't request or expect a CREDITS entry. Thanks. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Bug or feature? Probably bug with macros
On Mon, Dec 12, 2005 at 12:30:47AM +0100, Leopold Toetsch wrote:
> On Dec 11, 2005, at 23:45, Joshua Isom wrote:
> >.IfDebug(1,
> > print "var = "
> > print var
> >)
>
> As said, it was surprising me too. Anyway, I think typical use cases
> are debugging and I prefer a solution that boils down to no code at all
> for the non-debug case, like C's assert with -DNDEBUG.
Hm. Pondering...
* PIR is primarily a compiler target, not a human language. (Pasm,
in contrast, is an entirely non-human language.) So convenience is
not paramount.
* On the other hand, conditional compilation is cheap & helpful, so
why not?
* Forbidding commas in the expanded code is not OK. And requiring
backwhacked commas isn't OK either: too ugly, too much work to add
and remove conditionals around existing code.
So I guess we just need a robust multi-line quoting convention (to
pass multiple lines of code to macros). (Musing while typing:) How
about using braces as balanced delimeters when an open brace is the
first character:
.IfDebug(1, {
multi,line
stuff,with,commas
and even {nested} braces
goes
here
})
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Library loading - no more duplicates
On Mon, Dec 12, 2005 at 01:16:35PM +0100, Leopold Toetsch wrote: > As of r10458 Parrot doesn't load_bytecode the same file [1] twice anymore. Neat - this is a fine approximate solution until we have real pbc hashing, and *may* continue to be necessary even with hashing, depending on whether we can count on reproducible hashes from successive compilations of the same source file. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Bug or feature? Probably bug with macros
On Mon, Dec 12, 2005 at 02:07:41PM -0500, Will Coleda wrote: > On Dec 12, 2005, at 1:55 PM, Chip Salzenberg wrote: > >So I guess we just need a robust multi-line quoting convention (to > >pass multiple lines of code to macros). > > That sounds suspiciously like a HEREDOC. > > See: http://rt.perl.org/rt3/Ticket/Display.html?id=37600, which was > marked as rejected. That's worth reconsidering. I still think heredocs were a botch for Perl, which is generally not line-oriented. But PIR is definitely line-oriented, so it's not quite as much of a botch there. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Library loading - no more duplicates
On Tue, Dec 13, 2005 at 07:01:01PM +, Nicholas Clark wrote: > On Mon, Dec 12, 2005 at 10:08:24AM -0800, Chip Salzenberg wrote: > > Neat - this is a fine approximate solution until we have real pbc > > hashing, and *may* continue to be necessary even with hashing, > > depending on whether we can count on reproducible hashes from > > successive compilations of the same source file. > > Surely in that case we instead choose to hash based on the source file? That's a good fallback, but a perfect hash scheme would figure out that e.g. /tmp/bar.pbc is identical to the compilation output of /usr/share/bar.pir, and thus refuse to load one if the other has already been loaded. There are lots of ways to get good enough here; I'm not worried. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #38146] [TODO] OS.pmc - file copy
An aside: I suspect that OS.pmc is going to grow beyond maintainability (and fast loading) in the manner of Perl's POSIX module. But for now, it's absolutely great that we're collecting each portability hack into a single implementation. On Sat, Jan 07, 2006 at 01:04:29PM -1000, Joshua Hoblitt wrote: > I think it's prudent that OS.pmc's default copy() method behaves in the > same way as File::Copy::copy() as this is likely the lowest possible > common denominator across platforms (note that I said behavior, not > implementation). This is sufficient for the majority of file copy tasks > and will make prevent most people from having to worry about portability > issues. More sophisticated behavior, like metadata replication, should > be left to another method (perhaps syscopy()) that has platform specific > behavior(s). My first thought was that if you're not going to copy any metadata at all, then you're not looking at an OS method. But then then I remembered that some operating systems might actually have high-efficiency fast tricks for copying (e.g. the way Linux is going with its splice() system call proposals). So OS is fine. However, instead of shying away from the metadata problem, we should embrace it. Define copying with metadata as a standard feature with a standard interface. Something like: metacopy($src, $dest, owner => 0, # optional to copy mtime => 1, # mandatory to copy atime => undef, # forbidden to copy ... ) This provides a portable way of expressing what you need and want. If the current operating system can't accomodate you, you'll get a failure or exception (not making any assumptions on that point). Hm. If you say 'contents => undef', you might get a copying of metadata _only_. Neat. Come to think of it, Perl 5 could use one of these. And somebody should check with the p6 guys to see what they think of it ... they might be in a mood to (re)specify filesystem manipulation. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #38146] [TODO] OS.pmc - file copy
On Wed, Jan 11, 2006 at 04:16:55PM -0500, Joshua Juran wrote: > Since before System 7 (approaching two decades ago), Mac OS has had a > system call that exchanges the contents of two files. The purpose of > this call is to implement a 'safe save' strategy ... Is this still a system call in Mac OS X? -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #38146] [TODO] OS.pmc - file copy
On Thu, Jan 12, 2006 at 06:27:11AM -0800, jerry gay wrote:
> On 1/12/06, Alberto Manuel Brandão Simões <[EMAIL PROTECTED]> wrote:
> > I'm not implementing copy at the moment as I lack knowledge. I might
> > just write the default open/while(){write}/close method for cases when
> > everything else fails.
>
> since there seem to be non-File-specific methods destined for the File
> PMC, perhaps it could be renamed to something more appropriate, like
> FileSystem. thoughts?
I think getting away from "File" is good. By analogy with "OS", for
convenience, and in keeping with common usage, I like "FS". Today,
anyway.
PS: If some class is named "Filesystem" someday, the "S" shouldn't be
capitalized: "filesystem" is an established single term in CS.
"Filesys" maybe as a short form?
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #38262] get external modules out of the parrot repo
On Wed, Jan 18, 2006 at 12:10:34PM -0800, jerry gay wrote: > true, but i think DRY (don't repeat yourself) applies here. there's > already a standard repository for these modules, so why clutter the > parrot repo? Yes. Those who do not understand CPAN, etc. There should be a single CPAN bundle which, when installed, will pick up everything that a Parrot developer/tester requires. If you want to go the extra mile and create sub-bundles for other purposes, like testing-only, that's OK too. But unless the testers complain about having more Damian code sitting on their hard drive, I don't see any point in distinguishing dev from test. I envision a "fat parrot" tarball which includes not only the basic "thin parrot", but also required non-standard Perl modules, ICU, and other dependencies that a bare Unix system would not have. That should meet the needs of those who can't easily access the net during installation. That takes care of the tarball policies. Any system with a customized installer system will impose its own policies and practices on the developer who's foolhardy^Wbrave enough to package Parrot, so there's no point in me trying to dictate anything for them. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Q: pdd03 details
On Fri, Jan 20, 2006 at 07:56:55PM +0100, Leopold Toetsch wrote: > I'm currently rewriting the guts of argument passing which causes a few > tests to fail. > > 1) Is the :opt_flag optional? >.param string description :optional > # .param inthas_desc :opt_flag# <- is this always needed Yes, :opt_flag is optional, no, it is not always needed. (I get to be unambiguous, disagreeable, and helpful at the same time. :-)) > 2) Param count mismatches > > lua/t/function.t: > > local function g(a, b, ...) > # .param pmc var_a ; .param pmc var_b ; .param pmc argv :slurpy > ... > g(3) > > With param count checks turned on this would clearly fail. But what > without these checks? Are these checks mandatory, as pdd03 implies ... Checks are mandatory in supported Parrot. (Unsupported hacks, e.g. for debugging, can do anything, up to and including spawning nethack.) If the callee wanted to be flexible he would have to use :optional, and I can imagine that e.g. Perl 5 translations would always have to use it. > Thanks for clarification, Glad to help -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: argument count mismatch
On Fri, Jan 13, 2006 at 05:51:53PM +0100, Leopold Toetsch wrote: > This could be fixed by special-casing the initial call to ':main', > and then turn on param count checks if wanted. I think you'll need to invert that, given that code can be executed before :main, e.g. :immediate. Default the errors on, and if necessary[*], temporarily disable them for the :main call. [*] I actually don't have a problem requiring all :main subs to have explicit .param argv. But I'd also be OK with a code generator hack that inserts an automatic .param __argv in :main if the user doesn't say .param himself. Then the errors can be left on always. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: argument count mismatch
On Fri, Jan 20, 2006 at 11:41:45AM -0800, jerry gay wrote: > i suppose we need a design decision on this. We need a PIR version of get_params '()'. I'm OK with .no_params. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: named arguments
On Fri, Jan 13, 2006 at 02:29:49PM +0100, Leopold Toetsch wrote: > At argument opcodes level, a named argument are 2 items: name, var, > where the String 'name' is marked with the :named bit, e.g.: > > set_args '(0, 0x80, 0, 0x80, 0)', a, 'c', c, 'b', b I was pondering that issue earlier. Interleaving the strings with the registers would complicate existing logic in get_params just a bit. On the other hand, now that I think about it, :optional and :slurpy flags are already making it impossible to deduce parameter counts from the mere number of registers passed to get_params, so mixing in a few entries that must be ignored for arg count purposes wouldn't be any big deal. True? -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Supporting safe managed references
On Tue, Jan 24, 2006 at 12:11:14AM -, Jonathan Worthington wrote: > .NET has these managed reference thingies. They're basically like > pointers, but safe. [...] > > Making them work on Parrot is no problem. Making them work without > comprimising the safety of the VM is harder. Amongst the things you can > get a pointer to are parameters and local variables. Under .NET that means > stack locations; with Parrot that means registers. Indeed, and yet pointing to registers is not as fatal as you might imagine, nor does it require restructuring the VM by e.g. adding a register type. The trick is to keep references to registers in a way that notices when the register set is gone, or alternatively, that keeps the register set from going away. The latter is already achieved by the default LexPad implementation. Therefore, the representation of a safe pointer to a register would not, in fact, be a pointer to the register's storage in memory, but rather a weak reference (or, conceivably, a strong one? I doubt it) plus an integer register number. Is a pointer to a register the only tough case? And in what way is this different from the Reference type we're going to have to make work just for e.g. the Perl backslash operator? (Actually, I'm still a little fuzzy on actual usage patterns for this kind of thing. Otherwise I'd probably know those answers.) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: Supporting safe managed references
On Tue, Jan 24, 2006 at 03:52:39PM -, Jonathan Worthington wrote:
> "Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
> >The trick is to keep references to registers in a way that notices
> >when the register set is gone, or alternatively, that keeps the
> >register set from going away. The latter is already achieved by the
> >default LexPad implementation.
>
> Looking at it, I kinda see where you're coming from, but just stashing away
> and ensuring a LexPad PMC gets marked for a long as the reference gets
> marked is not enough, as a LexPad PMC doesn't control lifetime of a context
> structure, which is responsible for the registers. OTOH, taking a closure
> does keep the context and thus register frame in place, which is perhaps
> what you meant and seems workable.
That's a clever idea, creating a closure, but closures can't achieve any
kind of weak reference. They never want to let go of their context. So
that's a non-starter.
What I had in mind, was imitating whatever a closure does to hold onto a
context chain. I would detail that here except it's not on the top of my
brain except (1) the point is the imitation-rather-than-usage strategy,
and (2) it won't work anyway, also due to the need for a weak reference.
> >Therefore, the representation of a safe pointer to a register would
> >not, in fact, be a pointer to the register's storage in memory, but
> >rather a weak reference (or, conceivably, a strong one? I doubt it)
> >plus an integer register number.
>
> A weak reference to the closure PMC, I assume?
Well, what I meant at the time was a weak reference to the context, so
when the context evaporates on its own, you can be notified. But since
contexts aren't actually GC-able yet that's pretty much impossible now.
To get what you want, you may have to introduce cheap-ass pseudo-GC
pseudo-weak-reference mechanism for contexts. For example, a list of
callbacks attached to contexts that are to be called when the context's
refcount hits zero.
I'd prefer to reuse something in the engine already for those callbacks.
If a lightweight callback mechanism, with parameter, doesn't already
exist, then you could either use a closure for -that- (eh, too expensive)
or else invent such a mechanism for general use, with yourself as first
customer.
> Ah, and the reference might not be to an integer register, but that's
> just detail...
I imagined that the references would only ever be to -PMC- registers...?
> ... the managed reference PMC will hold a reference to the array PMC
> plus the element number (or object PMC and field name). Yes,
> performance will not be amazing, but that ain't really the goal.
That's a good approach, as far as it goes. Given the amazing variety of
"array" PMCs you can't possibly guarantee that there will be a memory
address there to use, even without movement issues.
But a .Net-specific solution seems unworthy. .Net translation isn't
nearly the only code that will want mutable pseudo-references to aggregate
elements. Seems to me that aggregates should have vtable methods to
create such, with the possibility of specializing. For example, a mutable
proxy object for %ENV{$foo} would not bother with hash manipulation; it
would just call getenv() and setenv().
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Supporting safe managed references
jeepers I mangled this paragraph On Tue, Jan 24, 2006 at 10:31:50AM -0800, Chip Salzenberg wrote: > What I had in mind, was imitating whatever a closure does to hold onto a > context chain. I would detail that here except it's not on the top of my > brain except (1) the point is the imitation-rather-than-usage strategy, > and (2) it won't work anyway, also due to the need for a weak reference. Let's try again: What I had in mind, was imitating whatever a closure does to hold onto a context chain. I would detail that here except (1) it's not on the top of my brain, (2) the point is the imitation-rather-than-usage -strategy-, and (3) it won't work anyway, also due to the need for a weak reference. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd21 notes
On Tue, Jan 24, 2006 at 01:36:23PM -0500, Matt Diephouse wrote: > Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > Some unsorted notes while reading through it: > > *) definition: "current namespace" > > *) namespace separator: "::" > > In this document, "::" indicates namespace nesting. > > As conventions, these are only here to make it easier to communicate > in the body of the PDD. They're there more for the writer of the > document than its readers. (Although they will hopefully make things > easier for the reader to understand as well.) I actually had the reader in mind, myself. But perhaps it's not worth the semantic confusion. Once you get used to ["a"; "b"] it isn't all -that- more confusing than "a::b". > Python's exporter can use type() to choose with add_* interface to use > if necessary. It *is* possible. Indeed, for any given HLL "L", no one is in a better position than L's exporter to know which of L's objects are more function-like than variable-like. That's why the idiom is source.export_to(target) rather than target.import_from(source) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd21 notes
{reordered for better reading}
On Mon, Jan 23, 2006 at 10:56:33PM +0100, Leopold Toetsch wrote:
> *)Typed Interface
>
> I've already layed out earlier in reply to Matt's proposal that this
> will be mostly unusable for e.g. Python.
First, please remember that when Python exports to Python, it's allowed to
notice that the source and target have compatible conventions and go
directly to the untyped interface, thus avoiding the whole typing issue.
Say, that gives me an idea. Python-like untyped namespaces are a
significant subpopulation.
Matt: How about a standard namespace method:
INTVAL is_typed()
which returns false for the simple Python-like unmangled namespaces? This
would allow -all- untyped namespaces to export to each other without hassle,
even if they're from different HLLs.
Meanwhile, for Python->Perl interoperability, I think Matt correctly
observes that e.g. python::namespace.export_to() will be able to make a good
decision in most cases as to whether a given Python object should be
exported as a sub or a variable. The Perl namespace's typed interface will
have to figure out what kind of variable it thinks it's getting. That
decision could be fairly arbitrary, but users will adapt to whatever
decision it tends to make.
As for the uncommon case in the uncommonner case -- oddball objects crossing
from Python to Perl -- well, that's where the Python-on-Parrot
implementation will just have to adapt to its environment, if it actually
wants to be useful to Perl users.
> *)Raw Interface
>
> The choosen method names are either misleading (e.g. 'add' vs
> infix:<+>) and/or not available as 'standard' vtable functions. Why not
> just use the Hash interface?
You may be right abou the Hash interface. I'll hack the doc and see if it
works.
> Some unsorted notes while reading through it:
> *) definition: "current namespace"
> ...
> (Pasm also has its own separate concept of current namespace ...
>
> Why and how? And what doest that mean? I don't see any difference WRT
> PASM code.
Don't read too much into the word "separate". I'm just distinguishing
the process of compilation from the process of execution.
> *) namespace separator: "::"
>In this document, "::" indicates namespace nesting.
>
> This looks too much misleading to me.
I doubt that problem will ever go away no matter what we write. I can
imagine that Parrot core warnings will someday include "You just created or
looked up a symbol with '::' in its name."
> *) ... unicode encoding
>
> I'm not sure if this is a good idea for language interop. Especially
> what charsets are allowed?
Um, huh? What could be better for language interop than a single unified
encoding like Unicode? And in what sense does "Unicode" leave "charset"
undefined?
> *)definition: "HLL" *and* Parrot
>
> Parrot isn't a HLL, but the document doesn't spec at all, where Parrot
> itself should put it's symbols.
I haven't made my mind up on that. The status quo is good enough ATM. It's
possible we'll be polluting the top level with a fair number of things even
at 1.0 time.
> *)load_library($S0, $S1, ...)
> We don't have any va_list syntax like that.
Oh yeah, what with all the :flat and :slurpy support I keep forgetting that
the PMC methods are more limited. I'll replace those with array PMCs.
> *)export_to($P0, ...)
>
> The wild card support $P1.export_to($P0, 'w*') seems to belong into the
> HLL.
The base export_to won't do much in the way of pattern recognition; if
wildcards are supported, they will be quite limited, and I'll make that
clearer. Anything more interesting will be implemented by HLLs' customized
namespace PMCs. I'll put that in the pdd.
> OTOH there isn't any 'import' hook that might be necessary to deal with
> type mismatches, interop issues, and whatnot.
That's the purpose of the typed interface on the target namespace.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd21 notes
Following up to myself, I just had an idea about expanding the typed
interface:
On Tue, Jan 24, 2006 at 12:26:30PM -0800, Chip Salzenberg wrote:
> The Perl namespace's typed interface will have to figure out what kind of
> variable it thinks it's getting. That decision could be fairly arbitrary,
> but users will adapt to whatever decision it tends to make.
The more I think about this, the less I like it.
It would be good for the typed interface to _allow_ an exporter to specify
more precisely what kind of variable it has, if it knows. For example:
add_scalar(STRING, PMC*)
add_array(STRING, PMC*)
add_hash(STRING, PMC*)
these would be defined to default to simply add_var(), but Perl namespaces
would implement them to do the obvious (prepending '$', '@', and '%',
respectively).
I'm less sure about the value of find_{scalar,array_hash}, but they'd be
cheap to write, and consistency is a Good Thing.
/me keeps thinking
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Supporting safe managed references
On Tue, Jan 24, 2006 at 08:49:55PM -, Jonathan Worthington wrote: > "Chip Salzenberg" <[EMAIL PROTECTED]> wrote: > >I'd prefer to reuse something in the engine already for those callbacks. > >If a lightweight callback mechanism, with parameter, doesn't already > >exist, then you could either use a closure for -that- (eh, too expensive) > >or else invent such a mechanism for general use, with yourself as first > >customer. > > There is a mechanism used to do this kinda thing for exit handlers > (src/exit.c), but it doesn't look particularly general. I guess leo will > know if there is something I've missed - leo, thoughts? I guess such a > mechanism probably shouldn't be much work to implement, though, and would > certainly be a nice, clean answer. Words I love to hear. Er, read. > >I imagined that the references would only ever be to -PMC- registers...? > > I wouldn't have thought so. I thought in Perl 6 the lowercased types like > "int" were to go in the I registers. Yes... > I think we'd still want to be able to create a reference to them though. No, sorry. "my int $a" means that $a is fast (good) but can't participate in any of the reindeer games like CALLER, MY, and references (bad). > In the .NET case, there's no reason not to use I registers for its > integers. Urque. So the real Reference PMC type actually doesn't do everything you want, and there's no point in waiting for it. As for your .Net-specific pointer PMC, if you're already keeping a contecxt pointer and an index, all you need in addition is a type enum for [INSP] and you're set. (Or separate subclasses of the pmc, whichever works better for you.) -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: pdd21 notes
On Tue, Jan 24, 2006 at 08:29:45PM -0500, Matt Diephouse wrote: > Chip Salzenberg <[EMAIL PROTECTED]> wrote: > > Say, that gives me an idea. Python-like untyped namespaces are a > > significant subpopulation. > > > > Matt: How about a standard namespace method: > > > > INTVAL is_typed() > > > > which returns false for the simple Python-like unmangled namespaces? This > > would allow -all- untyped namespaces to export to each other without hassle, > > even if they're from different HLLs. > > It definitely shouldn't be a problem. But it's only useful if you > think that languages won't be able to correctly identify their own > types [...] As you surmise, it's a performance hack. It's still useful if it just allows a significant number of export events to *avoid* the processing of identifying object types. Python-like namespaces will use this test *instead* of the "are you of the same namespace type as me" test for shortcut processing. -- Chip Salzenberg <[EMAIL PROTECTED]>
