Re: [svn:perl6-synopsis] r8698 - doc/trunk/design/syn
[EMAIL PROTECTED] schreef: > +The unary prefix operator C<*> casts a value to an C s/\ban\b/a > @@ -1340,7 +1340,7 @@ > PairTuple of two elements that serves as an one-element idem > +my $ref = [EMAIL PROTECTED]; # $ref is an Capture object - see S02 idem -- Affijn, Ruud "Gewoon is een tijger."
Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type
On Sun, Apr 16, 2006 at 11:22:40AM -0700, Patrick R. Michaud wrote: > This is a suggestion regarding double-quoted string literals > in Parrot. Currently double-quoted strings are always assumed > to be ASCII unless prefixed by a different charset identifier > such as 'unicode:' or 'iso-8859-1:'. Unfortunately, this means > that string literals like: > > $S1 = "He said, \xabHello\xbb" > $S2 = "3 \u2212 4 = \u207b 1" > > are treated as ASCII strings even though they obviously contain > codepoints outside of the ASCII range. (The first results in a > 'malformed string' error when compiled, the second chops off the > high-order bits of the \u sequence.) IIRC having ASCII as the default was a deliberate design choice to avoid the confusion of "is it iso-8859-1 or is it utf-8" when encountering a string literal with bytes outside the range 0-127. If so, then I assume that the behaviour of your second example is wrong - it should also be a malformed string. If PGE is always outputting UTF-8 literals, what stops it from always prefixing every literal "unicode:", even if it only uses Unicode characters 0 to 127? Nicholas Clark
[perl #38931] [RFE] Double-quoted strings automatically determine string type
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #38931] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38931 > This is a suggestion regarding double-quoted string literals in Parrot. Currently double-quoted strings are always assumed to be ASCII unless prefixed by a different charset identifier such as 'unicode:' or 'iso-8859-1:'. Unfortunately, this means that string literals like: $S1 = "He said, \xabHello\xbb" $S2 = "3 \u2212 4 = \u207b 1" are treated as ASCII strings even though they obviously contain codepoints outside of the ASCII range. (The first results in a 'malformed string' error when compiled, the second chops off the high-order bits of the \u sequence.) It would be really helpful to PIR emitters if Parrot could automatically use the presence of \u or \x in double-quotes to generate a 'unicode:' or 'iso-8859-1:' string (absent any other prefix specification which would override). If this were in place, producing a valid string literal for PIR would simply be (regardless of the encoding of $S0): $S1 = escape $S0 $S1 = concat '"', $S1 $S1 = concat $S1, '"' Currently, an emitter must also check for the presence of any \u or \x sequences in $S1, and then prefix the double-quoted literal with 'unicode:' or 'iso-8859-1:' accordingly. If this can't be easily done, then I will probably create a "parrot_escape" function in Data::String to handle the generation, but it would be great if Parrot could handle it natively. Thanks, Pm
Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type
On Sun, Apr 16, 2006 at 11:36:10AM -0700, Nicholas Clark via RT wrote: > IIRC having ASCII as the default was a deliberate design choice to avoid > the confusion of "is it iso-8859-1 or is it utf-8" when encountering a > string literal with bytes outside the range 0-127. Reasonable. Essentially I'm thinking the rule could be that any double-quoted literal with a \u sequence in it is utf-8, anything with \x (and no \u) is iso-8859-1, and all else is ASCII. I also proposed on IRC/#parrot that instead of automatically selecting the encoding, we have an "auto:" prefix for literals (or pick a better name) that would do the selection for us: $S1 = auto:"hello world" # ASCII $S2 = auto:"hello\nworld"# ASCII $S3 = auto:"hello \xabworld\xbb" # iso-8859-1 (or unicode) $S4 = auto:"3 \u2212 4 = \u207b 1" # Unicode Leo suggested doing it without "auto:" for the RFE. > If so, then I assume that the behaviour of your second example is wrong - it > should also be a malformed string. On this I'm only reporting what my parrot is telling me. :-) If it should be a malformed string, we should have a test for that (and I'll be glad to write it if this is the case). > If PGE is always outputting UTF-8 literals, what stops it from always > prefixing every literal "unicode:", even if it only uses Unicode characters > 0 to 127? The short answer is that some string operations on unicode strings currently require ICU in order to work properly, even if the string values don't contain any codepoints above 255. One such operation is "downcase", but there are others. So, if PGE prefixes every literal as "unicode:" (and this is how I originally had PGE) then systems w/o ICU inevitably fail with "no ICU library present" when certain string operations are attempted. Also, once introduced unicode strings tend can easily spread throughout the system, since an operation (e.g., concat) involving a UTF-8 string and an ASCII string produces a UTF-8 result even if all of the codepoints of the string value are in the ASCII range. Thus far PGE has handled this by looking at the resulting escaped literal and prefixing it with "unicode:" only if it will be needed -- i.e., if the escaped string has a '\x' or a '\u' somewhere in it. But now I'm starting to have to do this "check for unicode codepoint" in every PIR-emitting system I'm working with (PGE, APL, Perl 6, etc.), which is why I'm thinking that having PIR handle it directly would be a better choice. (And if we decide not to let PIR handle it, I'll create a library function for it.) I also realized this past week that using 'unicode:' on strings with \x (codepoints 128-255) may *still* be a bit too liberal -- the « french angles » will still cause "no ICU library present" errors, but would seemingly work just fine if iso-8859-1 is attempted. I'm not wanting to block systems w/o ICU from working on Perl 6, so falling back to iso-8859-1 in this case seems like the best of a bad situation. (OTOH, there are some potential problems with it on output.) Lastly, I suspect (and it's just a suspicion) that string operations on ASCII and iso-8859-1 strings are likely to be faster than their utf-8/unicode counterparts. If this is true, then the more strings that we can keep in ASCII, the better off we are. (And the vast majority of strings literals I seem to be generating in PIR contain only ASCII characters.) One other option is to make string operations such as downcase a bit smarter and figure out that it's okay to use the iso-8859-1 or ASCII algorithms/tables when the strings involved don't have any codepoints above 255. More comments and discussion welcome, Pm
Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type
On Sun, Apr 16, 2006 at 04:41:05PM -0500, Patrick R. Michaud wrote: > > If PGE is always outputting UTF-8 literals, what stops it from always > > prefixing every literal "unicode:", even if it only uses Unicode characters > > 0 to 127? > [...] > Also, once introduced unicode strings tend can easily spread > throughout the system, since an operation (e.g., concat) involving > a UTF-8 string and an ASCII string produces a UTF-8 result > even if all of the codepoints of the string value are in the > ASCII range. Oops, I just rechecked and this no longer seems to be the case. Or maybe it only happens in certain situations. However, my other points about the problem of using 'unicode:' on systems w/o ICU still stands. :-) Pm
Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type
On Sun, Apr 16, 2006 at 04:41:05PM -0500, Patrick R. Michaud wrote: > I also realized this past week that using 'unicode:' on > strings with \x (codepoints 128-255) may *still* be a bit > too liberal -- the « french angles » will still cause > "no ICU library present" errors, but would seemingly work > just fine if iso-8859-1 is attempted. I'm not wanting > to block systems w/o ICU from working on Perl 6, > so falling back to iso-8859-1 in this case seems like the > best of a bad situation. (OTOH, there are some potential > problems with it on output.) I haven't been near ICU for about a year, but last time I had dealings with it, it wasn't horribly portable. Furthermore, it had set itself up for trouble by having at least an n*m model of the world (compilers * operating systems) rather than an n+m (treat compiler related features independently of operating system related features). I was not impressed. Although clearly ICU is a good enough solution for now, so I'm not suggesting "burn it", even if it floats like a duck. > Lastly, I suspect (and it's just a suspicion) that string > operations on ASCII and iso-8859-1 strings are likely to be > faster than their utf-8/unicode counterparts. If this is > true, then the more strings that we can keep in ASCII, > the better off we are. (And the vast majority of strings > literals I seem to be generating in PIR contain only ASCII > characters.) > > One other option is to make string operations such as > downcase a bit smarter and figure out that it's okay > to use the iso-8859-1 or ASCII algorithms/tables when > the strings involved don't have any codepoints above 255. IIRC Jarkko's conclusion from having too much dealing with it in Perl 5 is avoid UTF-8 like the plague. Variable length encodings are fine for data exchange, but suck internally as soon as you want to manipulate them. With hindsight, his view was that probably Perl 5 should have gone for UCS-32 internally. (Oh, and don't repeat *the* Perl 5 Unicode fallacy, assuming that 8 bit data the user gave you happens to be in ISO-8859-1 if nothing told you this) I think Dan was thinking that internally everything should be fixed width, and for practical reasons pick the smallest of 8 bit, UCS-16 and UCS-32 internally. Convert variable width to fixed width (losslessly) the first time you need to do anything to it, and leave it that way. Specifically, even case conversion would be better done as fixed width, as there's at least one character where 1 of uppercase/titlecase/lowercase has a different width from the other 2. (That's before you get to special cases such as Greek sigma) Presumably therefore Dan's view was that while constants to the assembler might well be fed in as UTF-8, the generated bytecode should be using the tersest fixed width it can. I can see sense in this. Nicholas Clark
Variable-length PMC - level of need
On Thu, Apr 13, 2006 at 01:55:28AM +0200, Leopold Toetsch wrote: > On Apr 11, 2006, at 19:03, Chip Salzenberg wrote: > >2. "Reference Model" for value objects > > In Parrot, this mostly amounts to unique read-only PMCs. > > We'll have the read-only part, but the "unique" part, probably not. > > Can I/we read this as: "morphing for Parrot core PMCs is history"? - Or > in other words: differently sized PMCs (with a common (PObj) header) is > the way to go? Heh. When I want to say that, I think I know how to be clear. :-) But on the subject of PMC restructuring: * Your description of the status quo is that every access to the class- specific data in a PMC, e.g. to the array elements of a PMC array, require three indirections: One to the PMC, one to the PMC_EXT, and then one more to the user-defined data. But: I see extensive use of PMC_(struct|pmc|int|num|str)_val() in *.pmc. So triple indirection is hardly universal. Granted it is necessary for some cases, but the situation isn't as unliveable as I understood you to say earlier. + BTW, I don't see any use of PObj_buf(start|len) in *.pmc, and I find this odd. Surely there must be PMCs that would find it helpful to have both a pointer and a length without additional indirections...? * A consequence of variable-length PMCs would be a merging of PMC_EXT into PMC. Why wait for variable-length PMCs to get rid of PMC_EXT? Doing so now would eliminate an indirection and a pointer, which should help according to your theory. I'm told that PMC_EXT was introduced to help cache line behavior, but if I read the tea leaves^W^Wsource code correctly, sizeof(PMC) is right now five words on a 32-bit machine, an odd choice -- it should be possible to hit eight words instead, which ought to be cache-friendlier. -- Chip Salzenberg <[EMAIL PROTECTED]>
Re: [perl #38931] [RFE] Double-quoted strings automatically determine string type
Nicholas Clark wrote: > On Sun, Apr 16, 2006 at 11:22:40AM -0700, Patrick R. Michaud wrote: >> $S1 = "He said, \xabHello\xbb" >> $S2 = "3 \u2212 4 = \u207b 1" >> >> are treated as ASCII strings even though they obviously contain >> codepoints outside of the ASCII range. (The first results in a >> 'malformed string' error when compiled, the second chops off the >> high-order bits of the \u sequence.) > > IIRC having ASCII as the default was a deliberate design choice to avoid > the confusion of "is it iso-8859-1 or is it utf-8" when encountering a > string literal with bytes outside the range 0-127. Aye, it was auto-promoting to latin1 and was changed to ascii-by-default by me and Leo a while ago. > If so, then I assume that the behaviour of your second example is wrong - it > should also be a malformed string. > > If PGE is always outputting UTF-8 literals, what stops it from always > prefixing every literal "unicode:", even if it only uses Unicode characters > 0 to 127? Indeed, it would be much easier if unicode:"" on an ascii-only string can automatically go back to use ascii for representation, and choose to use utf8 (or better, latin1/ucs2) only iff there is high-bit parts in it. A Perlish way to solve this is to introduce another pragma, similar to "n_operators", that controls the encoding of all string literals of the PIR program: .pragma encoding utf8 Once written that way, you can simply use literal « » in the program, which reads better than \xab and \xbb anyway... :-) Audrey signature.asc Description: OpenPGP digital signature
[svn:perl6-synopsis] r8724 - doc/trunk/design/syn
Author: autrijus Date: Sun Apr 16 18:24:04 2006 New Revision: 8724 Modified: doc/trunk/design/syn/S06.pod doc/trunk/design/syn/S09.pod Log: * more typo cleanups promted by Dr. Ruud. Modified: doc/trunk/design/syn/S06.pod == --- doc/trunk/design/syn/S06.pod(original) +++ doc/trunk/design/syn/S06.podSun Apr 16 18:24:04 2006 @@ -705,7 +705,7 @@ =head2 Flattening argument lists -The unary prefix operator C<*> casts a value to an C +The unary prefix operator C<*> casts a value to a C object, then splices it into the argument list it occurs in. Casting C to C is a no-op: Modified: doc/trunk/design/syn/S09.pod == --- doc/trunk/design/syn/S09.pod(original) +++ doc/trunk/design/syn/S09.podSun Apr 16 18:24:04 2006 @@ -697,7 +697,7 @@ my $val := %hash; my @array; -my $ref = [EMAIL PROTECTED]; # $ref is an Capture object - see S02 +my $ref = [EMAIL PROTECTED]; # $ref is a Capture object - see S02 my %hash; %hash = "foo"; # duh
Non-Perl TAP implementations
I'm adding a section to Test::Harness::TAP on non-Perl TAP. http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod If you know of one, please send me some text to add. Thanks, xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Non-Perl TAP implementations
* Andy Lester <[EMAIL PROTECTED]> [2006-04-16T23:08:26] > I'm adding a section to Test::Harness::TAP on non-Perl TAP. > > http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod > > If you know of one, please send me some text to add. It's not really ready to be publicized, and I haven't touched it in a little while, but I'll mention PyTap: http://svn.codesimply.com/projects/pytap I'll get it in a useful state soon. Comments from more regular producers of Python code are welcome. -- rjbs signature.asc Description: Digital signature
[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 typed interface on the target namespace. However,
@@ -211,8 +231,9 @@
=item $P0 = name()
-Returns the name of the namespace as an array of strings. So
perl5:Some::Module
-would return an array containing "perl5", "Some", "Module".
+Returns the name of the namespace as an array of strings. So
Re: Non-Perl TAP implementations
* Ricardo SIGNES <[EMAIL PROTECTED]> [2006-04-16T23:33:19]
> It's not really ready to be publicized, and I haven't touched it in a little
> while, but I'll mention PyTap: http://svn.codesimply.com/projects/pytap
I got a request, off-list, for more info, so here is some:
PyTap will, when it's done, provide a simple, assertive
(Test::Builder/More-like) interface for writing tests in Python. It will
output TAP and will include the functionality found in Test::Builder and
Test::More. It will try to make it easy to add more test code (so you can
write your own TAP.StringDiff, for example.
Right now, it's got a fair bit of the basics needed to emulate Test::More, and
I think it's easy to add more stuff -- just like Test::Builder, there's a
singleton that you can get at easily.
I need to better identify and finish implementing the most basic tests. I am
not a Python guru, I just use it from time to time, so my aim may not be true.
I need to write tests for it, which means either relying on Perl for the tester
tester, or writing one in Python.
Here's a sample test, as found in my Subversion:
from TAP.Simple import *
plan(15)
ok(1)
ok(1, "everything is OK!")
ok(0, "always fails")
is_ok(10, 10, "is ten ten?")
is_ok(ok, ok, "even ok is ok!")
ok(id(ok),"ok is not the null pointer")
ok(True, "the Truth will set you ok")
ok(not False, "and nothing but the truth")
ok(False, "and we'll know if you lie to us")
isa_ok(10, int, "10")
isa_ok('ok', str, "some string")
ok(0,"zero is true", todo="be more like Ruby!")
ok(None, "none is true", skip="not possible in this universe")
eq_ok("not", "equal", "two strings are not equal");
--
rjbs
signature.asc
Description: Digital signature
[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
Re: Namespace roundup
This is an old message I'm replying to, so I'll copy most of it. On Fri, Mar 10, 2006 at 07:05:34PM +0100, Leopold Toetsch wrote: >Code snippet # NameSpace::name > > .sub main # '' actually parrot [1] > store_global 'x', $P0#parrot::x > cl = newclass 'Foo' #parrot::Foo > .end > >.namespace ['Foo'] # 'Foo' but really parrot::Foo > > .sub foo :method# Foo::foo actually parrot::Foo::foo > store_global 'x', $P0# Foo::x ... parrot::Foo::x > cl = newclass 'Bar' # Foo::Bar ... i.e. create nested name > .end > >.namespace ['Foo'; 'Bar'] # parrot::Foo::Bar >... > >.HLL "perl5"," # new top-level namespace > .sub 'x' # perl5::x >... > > [1] implicit HLL := 0, aka 'parrot' [2] default namespace > [2] the name might change still I still don't like "parrot" as the default namespace, but I dislike it a lot less than when you first suggested it. So no change for now. :-, > The default HLL namespace is the pseudo-root namespace for all namespace > operations except 'get_namespace' and 'add_namespace', which work from the > actual namespace root. Change needed: All namespace opcodes should be HLL-root-relative, without exception. I never meant otherwise, but I didn't document it right in a couple cases. Should be OK now. > The biggest change to the current implementqtion will be, that > 'store_global' and 'find_global' will work relative to the *current* > namespace and not to namespace-root like now. Right. -- Chip Salzenberg <[EMAIL PROTECTED]>
Namespaces TODO list, April 16 '06
Based on a status report from Leo {thanks!} and my recent revisions to
pdd21, here's a list of things that need to be done to bring parrot fully
into the new world of namespaces. The items are roughly in descending order
of importance. There's room for several contributors here
[[ NAMESPACE PMC ]]
* default namespace needs a typed interface
The good news is that the default {add,del,find}_{sub,var,namespace}()
methods don't have to do much, as the default namespace should be 100%
untyped (i.e. no name mangling should be done whatsoever).
* default namespace needs export_to()
[[ COMPILER PMC AND/OR HLL PMC ]]
* get suggestions for new HLL PMC distinct from compiler PMC, or get
reassurance that compiler PMCs are actually not all that heavy after all
I don't remember who added load_library() to the API of compiler PMCs. I
think that might be a mildly bad idea, since a compiler could conceivably
be a fairly heavyweight object to create. Perhaps an HLL PMC separate
from an HLL compiler PMC could solve this problem.
In the meantime, though, it will work. And we need a hook on which to
hang HLL-specific behavior. Thus the next item, in which we take this
idea and run with it:
* pdd21 wants compiler PMCs to implement load_library() and get_namespace()
I expanded the already documented load_library() with a second parameter
today, and also added get_namespace() to do namespace lookup within the
given HLL's namespace hierarchy.
Both of these methods have reasonable defaults, so it should be possible
for most HLLs to just inherit their
[[ MISC PARROT CORE ]]
* load_library opcode should use .load_library()
* get_namespace opcode should use .get_namespace()
These are obviously dependent on the previous item. :-)
* introspection and "parrot -t4" should display namespaces as ["a";"b";..]
[[ USER CODE ]]
* standard Parrot libraries not associated with any HLL should have their
own namespaces
For example, PGE should live in a ["pge"] namespace, or, conceivably,
under ["parrot";"PGE"]. In any case, the current double colons are
obsolete.
[[ PDD21 ]]
* pdd21 should document current namespace hierarchy
Currently the default compiler's namespace is 'parrot' (for PMCs) and
'__parrot_core' (for builtin MMD subs).
See also $ ./parrot examples/namespace/namespace_dump.pir |less
That's the list as I know it. Additions, corrections, and patches welcome.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Re: Non-Perl TAP implementations
On Apr 16, 2006, at 20:08, Andy Lester wrote: I'm adding a section to Test::Harness::TAP on non-Perl TAP. http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/ TAP.pod If you know of one, please send me some text to add. Test.Simple—JavaScript. It looks and acts just like tap, although in reality it's tracking test results in an object rather than scraping them from a print buffer. http://openjsan.org/doc/t/th/theory/Test/Simple/ Best, David
Re: Non-Perl TAP implementations
On Sunday 16 April 2006 20:08, Andy Lester wrote: > I'm adding a section to Test::Harness::TAP on non-Perl TAP. > > http://svn.perl.org/modules/Test-Harness/trunk/lib/Test/Harness/TAP.pod > > If you know of one, please send me some text to add. How non-Perl do you want? Does the Perl 6 version of Test.pm or Test::Builder/Test::More count? How about the Parrot versions? -- c
Re: Namespaces TODO list, April 16 '06
On Sunday 16 April 2006 22:00, Chip Salzenberg wrote: > * standard Parrot libraries not associated with any HLL should have their > own namespaces > > For example, PGE should live in a ["pge"] namespace, or, conceivably, > under ["parrot";"PGE"]. In any case, the current double colons are > obsolete. What should the syntax for creating new objects be? That is, if I define an object with its methods in the namespace [ 'PAST'; 'Node' ], how do I create a new instance of that class? .local pmc node node = new ??? -- c
first barest-bones Relation implementation committed
All, Following up with my recent on-#perl6 promises, I have started to implement a Perl 6 Relation class, in Pugs' ext/Relation/ directory. It is conceptually similar to the Perl 6 Set class, but operates in 2 main dimensions rather than 1. This barest-bones version has 2 main attributes, a new() constructor submethod, and an export_to_hash() method which outputs what you input to the first. It is not yet tested to compile or execute, but that will come soon, and it is visually more or less correct. The next main tasks, feature-wise, are to add methods for relational algebra, plus some that loosely resemble SQL operators (insert/update/delete). The next main tasks, implementation-wise, are to reimplement the attribute that stores the member tuples with a multi-dimensional hash, keyed on all the attributes, but I have to figure out the details first; meanwhile, it is an array of hashes. Also note that the number of dimensions and their types would vary for each Relation object, so I can't pre-declare those in the class. I should be continuing on this semi-daily, as I can afford time away from $work and other tasks. Feedback is welcome, although you may be better off waiting until I've done "the next main tasks". P.S. Note that this "Relation" class has nothing to do with my "Rosetta" DBMS project, aside from their operating in similar problem domains. The "Relation" is a proposal for a generally useful and simple-ish data type to include in Perl 6 itself, while "Rosetta" is a third-party toolkit for application building. -- Darren Duncan
