SVN ci privs for Cory - Parrot Common Lisp
Cory Spencer wrote: Okay, I've got things all moved over into the languages subdirectory and playing nicely with the Configure.pl/make process. Can I commit these to Subversion myself at some point (my CPAN id is cspencer), or is commit access fairly restricted? :) You'll need AFAIK a perl.org account. Then drop a note to Robert Spier who sets the commit priv bits. languages/* maintainers should be able to manage their stuff so I'm fully for providing ci privs to you. BTW don't forget to update MANIFEST. -c leo PS CC'ed to list
Thunking semantics of :=
Greetings. In implementing :=, I have discovered two different set of semantics in explantations. I will refer them as linking and thunking. The linking semantic is akin to hard links in filesystems. It takes the storage location in the RHS and binds its to the name in the LHS: $x := $x; # no-op ($x, $y) := ($y, $x); # swap The thunking semantic is akin to symbolic links in filesystems. It takes the expression in RHS and wraps it in an implicit closure, then give that closure a name to be triggered later. A12 has an example: $endpos := $string.chars;# thunk, changes as $string changes Now, those two semantics directly clash when the RHS can be interpreted both ways. One good example would be array dereference: my ($x, @a); $x := @a[-1]; @a = (1..100); say $x; Under the linking semantic, there is no location in RHS to bind yet. One possible interpretation is just autovivify it -- but [-1] is not autovivifiable, so it should throw out an fatal exception under the linking semantic right there. Under the thunking semantic, of course, it will work as expected. Assuming the thunking semantics however, I am not too sure about how this can possibly work: ($x, $y) := ($y, $x); # swap? One interpretation is that the RHS pad bindings are snapshotted, so future calls to $x always evaluates the bound $y at the RHS context, and hence give correct results. This would mean: my ($x, @a); $x := @a[0]; @a := ($x, $x, $x); $x := 1; say @a; # (undef, undef, undef) Okay, that looks good to me. Should I go ahead and implement the thunking semantics? Thanks, /Autrijus/ pgpRF0Zgx9Np5.pgp Description: PGP signature
Re: Thunking semantics of :=
Hi, Autrijus Tang wrote: my ($x, @a); $x := @a[0]; @a := ($x, $x, $x); $x := 1; say @a; # (undef, undef, undef) hm, I'd expect @a to be (1, 1, 1) (WE = when evaluated): my ($x, @a);# $x is undef WE, @a is () WE $x := @a[0];# $x is undef WE, @a is () WE @a := ($x, $x, $x); # $x is undef WE, @a is (undef, undef, undef) WE # But those undefs are bound to @a[0] -- # @a := (@a[0], @a[0], @a[0]); $x := 1;# $x is 1 WE, @a[0] is 1 WE say @a; # (1, 1, 1) And: my ($x, @a);# $x is undef WE, @a is () WE $x := @a[0];# $x is undef WE, @a is () WE @a = ($x, $x, $x); # $x is undef WE, @a is (undef, undef, undef) WE # Those undefs are real undefs $x := 1;# $x is 1 WE, @a[0] is 1 WE say @a; # (1, undef, undef) Opinions? --Ingo -- Linux, the choice of a GNU | To understand recursion, you must first generation on a dual AMD | understand recursion. Athlon!|
Re: -X's auto-(un)quoting?
Larry Wall skribis 2005-04-22 18:31 (-0700): I should point out that we're still contemplating breaking .foo() so it no longer means $_.foo(). I wish there were more keys on my keyboard... Which I think would be a very bad idea, so while I can (as long as no other decision has been made), I'm using the current syntax :) I even consider breaking compatibility with bare Perl 6, for my grammar, if that's necessary to get .foo to use the same implicit LHS as .[5]. Subs and loops are related, and aliasing the invocant as $_ the same way a loop aliases the loop variable as $_ makes sense to me. when you use a loop within a sub, do the same thing as when you use a loop within another loop: explicitly use the full name, or use OUTER::. We do, after all, have better ways of declaring private methods and functions now. so maybe we don't need to reserve _ for that anymore. I was planning on using prefixed underscore for macros that slurp up till the end of a line, so syntax highlighting could be adjusted for those things that would otherwise break. With non-underscore, I'd have to use a litter, or make my macro a prefix operator, which is more work. And it would save two characters over $_.foo(). But recovering C programmers will scream, and probably prefer _.foo(), even if it only saves one character. _ on my keyboards is two keys, shift and -, while . is only one. In fact, I find $_.foo even easier to type than _.foo, and better looking. Especially because the $ sigil is part of the name now, _ without sigil should not be used. Maybe it's time to raid Latin-1 for the next closest thing to a dot, middle dot: ·say(...); ·close or fail; Please, no. But I'm sure some will argue that's too subtle. (Hi, @LarryDamian.) String index for an array? say¹(...); close¹ or fail; Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo(). For that matter, I think repeating prefixed dots works just as well: .foo# $_.foo ..foo # $OUTER::_.foo # OUTER::$_.foo ...foo # $OUTER::OUTER::_.foo # OUTER::OUTER::$_.foo This shouldn't clash with yada, I think. (In the case it does (why would it?), adding parens is an obvious way to break ambiguity: (...).) Yes, especially the c: scheme. :-) I have no pity for Win32 users :) For all I care, they can use file:///c|/... or the awful MSIE variant file://c:\foo\bar. But I guess it's safe to treat single-letter schemes as Win32/DOS volumes, as there are no single-letter URI schemes. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Matt skribis 2005-04-22 21:55 (-0400): What about . for each level up you want to go? instead of 1.say, 2.say, 3.say you use .say, ..say, ...say (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Thunking semantics of :=
Autrijus Tang skribis 2005-04-23 18:51 (+0800):
Now, those two semantics directly clash when the RHS can be
interpreted both ways.
Not if methods for attributes like .chars promise to always return the
same variable, which would make even more sense if they were lvalue
methods. They can be put to use, like
.chars = 5; # truncate or pad
or they can be made read-only lvalues, as is a numeric literal:
$foo := 5;
$foo++; # error.
Under the linking semantic, there is no location in RHS to bind yet.
One possible interpretation is just autovivify it -- but [-1] is not
autovivifiable, so it should throw out an fatal exception under the
linking semantic right there. Under the thunking semantic, of course,
it will work as expected.
But when do you do when the index is non-literal?
$foo := @bar[$bar];
Does this work like creating an lvalue closure { @bar[$bar] } and
calling it, does it bind to the @bar with $bar as it was at the moment
of binding?
Is it true that every thunking thing is essentially a compile time
bind, and linking(aliasing) is a runtime thing? If so, can the semantics
each have their own operator? :=, ::=. I don't know if this makes any
sense, but that has something to do with me never understanding the
purpose of ::=.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
What about . for each level up you want to go? instead of 1.say, 2.say, 3.say you use .say, ..say, ...say (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. I like it too. In normal writing ... acts as a kind of 'think back' operator. Even though the writer uses it to signal an afterthought - it also makes the reader 'think back' to what preceded the afterthought. Syntax like .say ..say ...say enables the writer to add an afterthought and the reader to 'think back' to precisely the right scope. It allows you to have N scopes too .say, that would be cool. I hope this doesn't cause trouble for yada yada because I really like that operator too. Nige
Re: -X's auto-(un)quoting?
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd [EMAIL PROTECTED] wrote: Matt skribis 2005-04-22 21:55 (-0400): What about . for each level up you want to go? instead of 1.say, 2.say, 3.say you use .say, ..say, ...say (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Juerd Well I like it too. I just didn't think anyone would actually go for it. I guess I underestimated how crazy you guys are ;)
Re: [perl #35052] [MSWin32] PGE doesn't link
Ron Blaschke wrote: link -dll -def:libparrot.def -nologo -nodefaultlib -o pge.dll pge_parse.obj pge_gen.obj pge_opt.obj pge_parsep5.obj pge_parseglob.obj LINK : warning LNK4044: unrecognized option '/o'; ignored LINK : fatal error LNK1181: cannot open input file 'pge.dll' NMAKE : fatal error U1077: 'link' : return code '0x49d' Stop. I've had a look at things, here's what necessary to get Fpge.dll to link. 1) Fpge_gen.c uses Cvsnprintf, which is named C_vsnprintf on MSWin32. A simple hack would be to add the following to Fpge_gen.c. #ifdef WIN32 # define vsnprintf _vsnprintf #endif 2) Linkage for Fpge.dll should read something like this. link -dll -nologo -nodefaultlib -out:pge.dll pge_parse.obj pge_gen.obj pge_opt.obj pge_parsep5.obj pge_parseglob.obj msvcrt.lib kernel32.lib IMHO, compilation and linkage feels quite messy as a whole. I am not sure how to get the current link command to look like the one above, without doing something akin to Fdynclasses/build.pl (cf line 40+). Ron
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 06:51:04PM +0800, Autrijus Tang wrote:
: Greetings. In implementing :=, I have discovered two different
: set of semantics in explantations. I will refer them as linking and
: thunking.
Congratulations--you've rediscovered call by ref and call by name,
but computer scientists tend to associate those concepts with calls
for some reason. :-)
In fact, the name thunk was invented for Algol, because it did
call-by-name, and was widely reviled for its inability to swap
two parameters. Nevertheless, computer scientists liked the
definitionalness of call-by-name, and have used it to write
pseudocode for years. It's hard to implement efficiently, but it
does let you defer some decisions about lvalueness.
: The linking semantic is akin to hard links in filesystems.
: It takes the storage location in the RHS and binds its to the
: name in the LHS:
:
: $x := $x; # no-op
: ($x, $y) := ($y, $x); # swap
:
: The thunking semantic is akin to symbolic links in filesystems.
: It takes the expression in RHS and wraps it in an implicit closure,
: then give that closure a name to be triggered later.
: A12 has an example:
:
: $endpos := $string.chars;# thunk, changes as $string changes
As Juerd pointed out, a ref to an lvalue works just as well to track
changes. The := operator is intended to use hard linking semantics.
: Now, those two semantics directly clash when the RHS can be
: interpreted both ways. One good example would be array dereference:
:
: my ($x, @a);
: $x := @a[-1];
: @a = (1..100);
: say $x;
:
: Under the linking semantic, there is no location in RHS to bind yet.
: One possible interpretation is just autovivify it -- but [-1] is not
: autovivifiable, so it should throw out an fatal exception under the
: linking semantic right there. Under the thunking semantic, of course,
: it will work as expected.
I would prefer the exception.
: Assuming the thunking semantics however, I am not too sure about how
: this can possibly work:
:
: ($x, $y) := ($y, $x); # swap?
:
: One interpretation is that the RHS pad bindings are snapshotted,
: so future calls to $x always evaluates the bound $y at the RHS
: context, and hence give correct results. This would mean:
:
: my ($x, @a);
: $x := @a[0];
: @a := ($x, $x, $x);
: $x := 1;
: say @a; # (undef, undef, undef)
:
: Okay, that looks good to me. Should I go ahead and implement
: the thunking semantics?
No, I think just treat the RHS as a context that says: Give me
an lvalue if you can, otherwise give me an rvalue. One of the
motivations for making {...} always return a closure is so that it
would be really easy to specify a thunk when you really want one.
But the flip side of that is we want to discourage implicit thunking
in favor of explicit thunking. One benefit of that is that we give
the optimizer more information about the intent of the programmer.
It will be better for efficiency if we don't have to clone a bunch
of closures unnecessarily.
We could make some kind of ruling that binding closures to a container
gives that closure the ability to proxy for the container if you use
the container as something other than a closure. But there are
probably inconsistencies in that approach, unless we only allow
such binding to containers that could not be used directly as a
a closure reference. Have to think about that some more.
Larry
bug in array.pmc set_integer_same?
Looking at the code in array.pmc's set_integer_same I see:
=item Cvoid set_integer_same(PMC* value)
Sets the length of the array to the number of elements in C*value.
=cut
*/
void set_integer_same (PMC* value) {
INTVAL size = DYNSELF.elements();
list_set_length(INTERP, (List *) PMC_data(SELF) ,size);
}
Surely that DYNSELF should be value? As is, I think that this method is a
no-op.
Nicholas Clark
Binding and the Proxy class
Hi,
my $x = new Proxy: FETCH = { foo() }, STORE = { bar($^new) };
$x ~~ Proxy; # true
$x = 42; # neither foo nor bar called
$x ~~ Num; # true
my $y := new Proxy: FETCH = { foo() }, STORE = { bar($^new) };
$y ~~ Proxy; # false (unless foo returns a Proxy object)
$y = 42; # bar(42) called
$y ~~ Proxy; # still false (unless foo returns a Proxy object)
say $y; # foo() called
Correct?
BTW, is it possible to implement the Proxy class in pure Perl? (I don't
think so.)
--Ingo
--
Linux, the choice of a GNU | Row, row, row your bits, gently down the
generation on a dual AMD | stream...
Athlon!|
Re: -X's auto-(un)quoting?
Matt wrote: On Sat, 23 Apr 2005 07:25:10 -0400, Juerd [EMAIL PROTECTED] wrote: Matt skribis 2005-04-22 21:55 (-0400): What about . for each level up you want to go? instead of 1.say, 2.say, 3.say you use .say, ..say, ...say (Ok, I'm just kidding.. really!) I read your message after I suggested the same thing (I'm too impatient to read all new messages before sending replies). Why were you just kidding? I think it's a great idea. Well I like it too. I just didn't think anyone would actually go for it. I guess I underestimated how crazy you guys are ;) After some further thought (and a phone talk with Larry), I now think that all of these counted-level solutions (even my proposal of _2.foo(), etc.) are a bad idea. They have a similar problems to constructs like next 5; meaning jump to the next iteration of the loop 5 level out. Any time you refactor you code and change levels, they break in a subtle and very hard to debug way, causing mysterious errors. Just like the current Perl construct of labeled loops so that you can talk about the target loop explicitly, the proper solution for up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named binding like $uplevel_topic := $_; at that upper level and then use that to refer to it at lower levels. Beside is ...foo(); seven of eight levels up? Any other way than explicit naming is madness; leading to unreadable and unmaintainable code. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Binding and the Proxy class
Ingo Blechschmidt skribis 2005-04-23 19:42 (+0200): BTW, is it possible to implement the Proxy class in pure Perl? (I don't think so.) It would have to be possible, because Perl 6 will be written in Perl 6. (I like that Perl 6 will be written in Perl 6, because as Perl 6 is very fast, Perl 6 will probably be fast too. We don't need C for speed ;)) Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
On Sat, 23 Apr 2005 13:55:17 -0400, Mark A. Biggar [EMAIL PROTECTED] wrote:
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea. They have a similar problems to constructs like
next 5; meaning jump to the next iteration of the loop 5 level out.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors. Just like
the current Perl construct of labeled loops so that you can talk about
the target loop explicitly, the proper solution for up-level access to
$OUTER::OUTER::...::OUTER::_ is to create a named binding like
$uplevel_topic := $_; at that upper level and then use that to refer
to it at lower levels. Beside is ...foo(); seven of eight levels
up? Any other way than explicit naming is madness; leading to
unreadable and unmaintainable code.
Hm.. didn't really think of that. Though, how often would that really
happen? You can just explicility refer to the topic if you refactor. So
long as there is another way, I'm not sure that problem constitutes not
putting in such a shortcut.
I do see this as a being a bit confusing though:
given open 'file a' {
given open 'file b' {
given open 'file c' {
.say(...);
..say(...);
...say(...);
}
}
}
Doesn't that just encourage writing confusing code? Also, does anyone
else initial read it as doing say on file a first, then b, then c; instead
of c, b, a?
Re: -X's auto-(un)quoting?
Mark A. Biggar skribis 2005-04-23 10:55 (-0700):
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea.
In that case, why even have OUTER::?
I agree, though, and have always found this, that using the full name
(binding one if it doesn't have one already) is the better solution.
given returns_object() - $foo {
when SomeClass { ... }
}
I think we all agree that smart match (implied by when) should work on
$_. The following is consistent with the above:
method ($foo: @bar) {
when SomeClass { ... }
}
Only the first line changes, and everything still works as expected.
The same would work very well for method calls:
method ($foo: @bar) {
.method;
}
I would expect that if we change the first line back (less academically,
copied and pasted the code elsewhere), it would still work on the same
thing.
given returns_object - $foo {
.method;
}
The block passed to given aliases the first argument to $_. Methods
should do the same. And I really beleave that using a : to separate
instead of , does not make the invocant any less the first argument.
They have a similar problems to constructs like next 5; meaning jump
to the next iteration of the loop 5 level out.
Yes, that's ugly.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors.
Same thing for having one thing default to $_ and another to $self, in a
way. If everything defaults to $_, which may or may not be the same
thing as $self, things become more predictable, and you can when
refactoring just copy the body of a loop to a new method without
breaking it.
Just like the current Perl construct of labeled loops so that you
can talk about the target loop explicitly, the proper solution for
up-level access to $OUTER::OUTER::...::OUTER::_ is to create a named
binding like $uplevel_topic := $_; at that upper level and then use
that to refer to it at lower levels.
Indeed. Fortunately, many built in constructs involving blocks that get
arguments already set up that binding for you.
Beside is ...foo(); seven of eight levels up?
A rather irrelevant question, IMHO. It is as irrelevant as the similar
Is 5521243 approximately .5 million or 5.5 million?, because just as
you can write 5_521_243 to make the number more clear, you could write
... ... .foo();
to show it's 7 dots.
Any other way than explicit naming is madness; leading to unreadable
and unmaintainable code.
Not if implict naming (completely implicit, that is, so without any
indication of level even) is consistent in what it means. Currently,
things default to $_ in almost every place where a value is needed but
left out. I'd hate to see that change to some other variable for only a
portion of the operations now defaulting to $_.
Automatic binding of the invocant as $_ and the possibility to provide
your own name for the thing (either by specifying it in the signature or
by explicitly using the := operator) makes that .method defaulting to
working on $_ is not a problem.
A method's block shouldn't be too different from a given's block, or any
other closure for that matter. They should both topicalize using the
same semantics, IMO.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
Matt Creenan skribis 2005-04-23 14:19 (-0400): Hm.. didn't really think of that. Though, how often would that really happen? Often -- this is exactly the same problem as Python has with its significant indenting. Move code around and you have to manually adjust it to the new levels. The problem with ..foo is less apparent because you're likely to copy all the levels at once, and it's relative rather than absolute. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: -X's auto-(un)quoting?
On Sat, 23 Apr 2005 14:21:06 -0400, Juerd [EMAIL PROTECTED] wrote: Matt Creenan skribis 2005-04-23 14:19 (-0400): Hm.. didn't really think of that. Though, how often would that really happen? Often -- this is exactly the same problem as Python has with its significant indenting. Move code around and you have to manually adjust it to the new levels. The problem with ..foo is less apparent because you're likely to copy all the levels at once, and it's relative rather than absolute. Juerd Personally I'd never use 3 levels or above. ..say or .say is it. Beyond that, I would start naming the topics. Also, I would only use ..say on quick and dirty code probably. But why are we so keen on finding a way to save a few characters isntead of just naming the topic which leads to more readble code? If it's not self-descriptive, I think it does more harm than good.
Re: -X's auto-(un)quoting?
Personally I'd never use 3 levels or above. ..say or .say is it. Beyond that, I would start naming the topics. Also, I would only use ..say on quick and dirty code probably. But why are we so keen on finding a way to save a few characters isntead of just naming the topic which leads to more readble code? If it's not self-descriptive, I think it does more harm than good. then how about alias $OUTER::_ with $__ as a special exception? it looks familiar (maybe too much), but as it would be used in quick and dirty code, there wouldn't be that much $_ to confuse it with. or is $__ already taken? brano tichy [EMAIL PROTECTED]
morph()ing
When writing morph methods for PMC classes, am I right in thinking that if morphing from class A to class B, where both use the PMC_struct_val to store structures of different types, it's totally up to the morph method to know how to correctly dispose of the old class A structure, and create and initialised a class B structure? In effect morph has to be friends of both A and B, because it needs to break encapsulation? Nicholas Clark
Pugs 6.2.1 released
I am happy to announce the availability of Pugs 6.2.1 on CPAN, with
totally rewritten Context and Type code, a new OO core, call-by-values
bindings, as well as a huge number of other improvements and fixes.
http://autrijus.org/dist/Perl6-Pugs-6.2.1.tar.gz
SIZE = 732656
SHA1 = eba45bf9c2ddbe4d207ee32b5f90ae2c30cd6b48
Thanks to everyone who have tried out 6.2.0 and contributed helpful
suggestions; 6.2.1 is, I hope, a much more stable release for people
who are writing real-world programs in it.
Again, my utmost gratitude to all our lambdacamels for making this
release possible and enjoyable.
Cheers!
/Autrijus/
== Changes for 6.2.1 - April 24, 2005
=== Pugs Internals
* Unification of the quoting code, most quoting constructs now work
** now works
** Regular expressions are parsed as `qq//`, but without backslash protection
** Hash subscripts using `` or `` are parsed as general quotations
** This means interpolation, etc. is done just like `q:w` or `qq:ww`
** `$delim` not interpolate in quoting constructs
** `$)`, `$]`, `$#` and `$ws` do not interpolate in `rx:P5//` constructs
* Assigning a List into a Scalar vivifies it into an Array
* Assigning a `List` into a `Scalar` now vivifies it into an `Array`
* Assigning to pairs now works as expected
* Autoextracted `$_` is now `rw` by default
* Better handling for size extensions and `exists()` for negative indecies
* Bindings implemented for multiple variables
* Experimental support for `eval_haskell()` builtin
* First stab at a lexical `$*CWD` variable
* Index in slices now defaults to List: [EMAIL PROTECTED]()]` now works
* Initialize readline properly in interactive shell
* Junctive types in subroutine signatures `sub foo (Str|Array)`
* New builtins: `~`, `kill()`, `splice`, `readdir()` (list context only)
* Pairs are now always objects and never values
* Passing too many slurpy arguments is now an exception
* Regexps now support `:P5` and `:Perl5` as well as `:perl5`
* Storing into negative array elements now works
* The `Any` parameter type no longer inhibits juctive autothreading
* Variables in rvalue context no longer returns its references
* `%h` now acts just like `%h{}` in both lhs and rhs
* `%hx` now mean `%h{'x'}` instead of `%h{'x',}`
* `'key' = val` now works as named param just like `key = val` did
* `(sub {3} | sub {2})()` implemented
* `:P5` flags now work as `:P5imsgx` and `:i` `:g` works too
* `:l filename` no longer needs double quotes in the Shell
* `` (list quoting) is now always in list context
* `is rw` and `is copy` implemented in full
* `list()` now actually imposes list context
* `want()` has been implemented, returning a simple string
=== Tests, Examples and Documentations
* Many new tests and cleanup of older tests, we are now at 4500+ tests
** removed all usages of todo_* functions since the are now deprecated
* Added `isnt()`, `unlike()`, `skip_rest`, `throws_ok` functions to `Test.pm`
* Added some Perl 6 related talks in `docs/talks`
* Added the `make smoke` target to `Makefile`
* Additions and improvements to the `util/catalog_tests.pl` scripts
* Improvements to `examples/network` and added README file
* Improvments to the `util/p5_to_p6.pl` script
* Major refactoring of the Test.pm module (see `ext/Test/ChangeLog` for details)
* Memory game, first web application written in Perl 6
* New Perl 6 tutorial generator ported to Pugs in `examples/tutorial_gen/`
* New naive baysian text classifier add in `examples/naive_bayesian`
* New quote generator script in `examples/motd`
* Params are now loaded on-demand in `CGI.pm` to take advantage of encoding
* Several new additions to the Perl 6 Cookbook
* Svn graphing script added to `util/`
* Test smoke scripts converted to use `Test::Tap::Model`
* The `fp.p6` file has been broken into seperate files in `examples/fp/`
* UTF-8 URL decoding added to `CGI.pm`
=== Bug Fixes
* Accessing [EMAIL PROTECTED] (without setting it) no longer extends [EMAIL
PROTECTED]
* Code blocks as subroutine arguments now results in correct arity
* Code objects now returns the correct subtypes
* Comma is no longer flattened as arguments for infix and postfix functions
* Corrected `chmod` prototype
* Fixed infinite bug when evaluating `+((1|2).values)`
* Fixed passing references into bound variables in subroutines
* Fixed segfault with `:r` in interactive shell
* Hyper operators now extends to the longer, not shorter, lists
* Inf/NaN handling for `**` now works
* Manpage for `Perl6::Pugs` now generated correctly
* RValues at the right hand of array assignment are flattened to prevent loops
* Restore `%hstr = want()` to impose string context on rhs
* Setting `$*CWD` to invalid directory is no longer fatal
* Slurpy params now applies *-flattening to its arguments
* `$x = 1|2; $x = 3` no longer treats `1|2` as a constant
* `%ha` or `%h{'a'}` no longer eats trailing spaces interpolated strings
* `(1,(2,3))` in scalar context is now `[1,[2,3]]`
* `**` no longer truncates the exponent to integer
*
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 10:21:56AM -0700, Larry Wall wrote: : Now, those two semantics directly clash when the RHS can be : interpreted both ways. One good example would be array dereference: : : my ($x, @a); : $x := @a[-1]; : @a = (1..100); : say $x; : : Under the linking semantic, there is no location in RHS to bind yet. : One possible interpretation is just autovivify it -- but [-1] is not : autovivifiable, so it should throw out an fatal exception under the : linking semantic right there. Under the thunking semantic, of course, : it will work as expected. I would prefer the exception. Alright. I wish I had seen this mail earlier -- because I just implemented the call-by-name semantics with snapshotting of RHS pad. Oh well. At least the same code can be salvaged to make iThreads and serializable continuations work. So, hm. What does this do? my ($x, @a); $x := @a[0];# vivified or not? @a = (1..100); say $x; Thanks, /Autrijus/ pgpCuMI650CeH.pgp Description: PGP signature
Re: Thunking semantics of :=
Autrijus Tang skribis 2005-04-24 3:47 (+0800): $x := @a[0]; # vivified or not? Vivified, because you're taking a reference (not at language level) and you can't have a reference (at internal level) pointing to something that doesn't exist. At language level, you can, but only symbolically. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 09:50:26PM +0200, Juerd wrote: Autrijus Tang skribis 2005-04-24 3:47 (+0800): $x := @a[0];# vivified or not? Vivified, because you're taking a reference (not at language level) and you can't have a reference (at internal level) pointing to something that doesn't exist. At language level, you can, but only symbolically. Okay. Implemented as r2260, with full call-by-value semantics as defined by Larry's previous post. `bindings.t` passes under either semantics, as expected. Please sanity-check the following: pugs my ($x, @a); $x := @a[-1]; $x = 3; @a *** Error: Modification of non-creatable array value attempted pugs my ($x, @a); $x := @a[0]x[1]y; $x = 3; @a[0]x[1]y 3 pugs my ($x, @a); $x := [EMAIL PROTECTED]; $x = 3 *** Error: Can't modify constant item Thanks, /Autrijus/ pgpi8cUizBanW.pgp Description: PGP signature
Re: Thunking semantics of :=
Autrijus Tang skribis 2005-04-24 3:58 (+0800): Please sanity-check the following: pugs my ($x, @a); $x := @a[-1]; $x = 3; @a *** Error: Modification of non-creatable array value attempted Pass. (For reference: The error is in the second statement.) pugs my ($x, @a); $x := @a[0]x[1]y; $x = 3; @a[0]x[1]y 3 Pass. pugs my ($x, @a); $x := [EMAIL PROTECTED]; $x = 3 *** Error: Can't modify constant item Pass, provided that [EMAIL PROTECTED] (@a.elems) is rvalue. If it's lvalue, then @a should grow to 3 elements instead. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Thunking semantics of :=
On Sat, Apr 23, 2005 at 10:07:05PM +0200, Juerd wrote: : Autrijus Tang skribis 2005-04-24 3:58 (+0800): : Please sanity-check the following: : pugs my ($x, @a); $x := @a[-1]; $x = 3; @a : *** Error: Modification of non-creatable array value attempted : : Pass. (For reference: The error is in the second statement.) : : pugs my ($x, @a); $x := @a[0]x[1]y; $x = 3; @a[0]x[1]y : 3 : : Pass. : : pugs my ($x, @a); $x := [EMAIL PROTECTED]; $x = 3 : *** Error: Can't modify constant item : : Pass, provided that [EMAIL PROTECTED] (@a.elems) is rvalue. If it's lvalue, then @a : should grow to 3 elements instead. rvalue, I think. Extending an array should probably be a special method, though we might allow @a.elems = 3; or some such. Larry
Re: Binding and the Proxy class
Juerd writes: Ingo Blechschmidt skribis 2005-04-23 19:42 (+0200): BTW, is it possible to implement the Proxy class in pure Perl? (I don't think so.) It would have to be possible, because Perl 6 will be written in Perl 6. (I like that Perl 6 will be written in Perl 6, because as Perl 6 is very fast, Perl 6 will probably be fast too. We don't need C for speed ;)) I don't like how Python is will be written in Python. Since Python is very slow, Python will probably be slow too. :-) Luke
Re: -X's auto-(un)quoting?
Larry Wall wrote:
I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
That almost makes sense, given that $^a is like $_. It also points vaguely
upward toward some antecedent. I could maybe get used to that, if I
tried real hard for a long time. Almost makes we wish we could rename
$_ to $^ though. Hmm...
I like this.
Only I'd have C .foo means C $_.foo and C ^foo mean C
$self.foo , assuming $self is the first invocant.
Why swap them? because $_ is known for performing magical disappearing
acts all over the place, and the ^ ties in with the $^x of parameters.
As for shortcuts to $OUTER::_, perhaps $-, if it's not put to some
better usage, but anything beyond that is getting too obscure for common
usage.
-- Rod Adams
Re: Thunking semantics of :=
On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: Oh well. At least the same code can be salvaged to make iThreads Please. No iThreads behaviour in Perl 6. Nobody uses them and whilst stable, the implementation is broken in so many way. But worse, the underlying semantics are completely and utterly wrong.
Re: Thunking semantics of :=
On Sun, Apr 24, 2005 at 03:37:23AM +, Nigel Sandever wrote: : On Sun, 24 Apr 2005 03:47:42 +0800, [EMAIL PROTECTED] (Autrijus Tang) wrote: : : Oh well. At least the same code can be salvaged to make iThreads : : Please. No iThreads behaviour in Perl 6. : : Nobody uses them and whilst stable, the implementation is broken in so many way. : : But worse, the underlying semantics are completely and utterly wrong. Are you confusing iThreads with pThreads? Or are you recommending we go back to the pThreads fiasco? From what I've read, the trend in most modern implementations of concurrency is away from shared state by default, essentially because shared memory simply doesn't scale up well enough in hardware, and coordinating shared state is not terribly efficient without shared memory. If you are claiming that modern computer scientists are completely and utterly wrong in moving that direction, well, that's your privilege. But you should be prepared for a little pushback on that subject, especially as you are merely badmouthing something without goodmouthing something else in it's place. Larry
for all(@foo) {...}
Hi,
I'm trying to understand the following section in S03:
S03/Junctive operators
Junctions are specifically unordered. So if you say
for all(@foo) {...}
it indicates to the compiler that there is no coupling between loop
iterations and they can be run in any order or even in parallel.
Is this a for on a one element list, which happens to
be a junction, or does the all() flatten?
Is the whole block run once with 1,2 and 3, or does the
junction go into the block and autothread each operation?
for all(1,2,3) {
next if $_ 2; # testing 1 or all(1,2,3) ?
%got{$_} = 1;
}
say %got.perl; # (('2', 1), ('3', 1)) or () ?
The no coupling in s03 suggests to me that the right
answer is (('2', 1), ('3', 1)), but I'm just guessing.
Brad
--
To ask when you already know is politeness. To ask when you don't know
is the rule. -- Hagakure http://bereft.net/hagakure/
Building an incomplete code generator into Parrot
Well I started the AMD64 code generator. I don't have much available yet -- just enough for what seems to be necessary to run anything at all. Parrot_jit_begin makes calls to MOV instructions that are implemented, and I have a NOP implemented. Is this the bare minimum? I was hoping for some insights into how I can incorporate this into a build and get the VM to recognize my code generator for trivial test programs I want to send it. I haven't been able to test if any of this works yet. As of right now, I still have the i386 code.jit file, and I don't know how that works when I don't have all the requisite instructions implemented. Can the core.jit only list the opcodes I currently support? Do I need stubs for all the opcodes?
Re: for all(@foo) {...}
On Sun, Apr 24, 2005 at 03:02:16PM +1000, Brad Bowman wrote:
: Hi,
:
: I'm trying to understand the following section in S03:
:
: S03/Junctive operators
:
: Junctions are specifically unordered. So if you say
: for all(@foo) {...}
: it indicates to the compiler that there is no coupling between loop
: iterations and they can be run in any order or even in parallel.
:
: Is this a for on a one element list, which happens to
: be a junction, or does the all() flatten?
No, S03 is probably just wrong there. Junctions are scalar values, and
don't flatten in list context. Maybe we need something like:
for =all(@foo) {...}
to iterate the junction.
: Is the whole block run once with 1,2 and 3, or does the
: junction go into the block and autothread each operation?
I expect =all(@foo) would do the former, while all(@foo) would do
the latter, in which case you might as well have used given instead.
: for all(1,2,3) {
:next if $_ 2; # testing 1 or all(1,2,3) ?
:%got{$_} = 1;
: }
: say %got.perl; # (('2', 1), ('3', 1)) or () ?
Well, { 2 = 1, 3 = 1 } is the more likely notation.
: The no coupling in s03 suggests to me that the right
: answer is (('2', 1), ('3', 1)), but I'm just guessing.
I think =all(@foo) should do what you expect there. Without the =
it should return { 1 = 1, 2 = 1, 3 = 1 } since there's only one
loop iteration, and it is *not* true that all(1,2,3) 2. If you'd
said
for any(1,2,3) {...}
then it would have done the next, because 1 2.
I should say that I don't see that =all() is different from =any().
They each just produce a list in random order. Though I suppose,
if we say that =one(1,2,3) should randomly pick one value, then
=any(1,2,3) should pick anywhere from 1 to 3 values. And, of course,
=none(1,2,3) should return a list of all the things that aren't 1, 2,
or 3 in random order. Maybe a lazy implementation will be beneficial
at that point. :-)
Larry
Re: for all(@foo) {...}
On Sat, Apr 23, 2005 at 10:29:20PM -0700, Larry Wall wrote:
: On Sun, Apr 24, 2005 at 03:02:16PM +1000, Brad Bowman wrote:
: : Hi,
: :
: : I'm trying to understand the following section in S03:
: :
: : S03/Junctive operators
: :
: : Junctions are specifically unordered. So if you say
: : for all(@foo) {...}
: : it indicates to the compiler that there is no coupling between loop
: : iterations and they can be run in any order or even in parallel.
: :
: : Is this a for on a one element list, which happens to
: : be a junction, or does the all() flatten?
:
: No, S03 is probably just wrong there. Junctions are scalar values, and
: don't flatten in list context. Maybe we need something like:
:
: for =all(@foo) {...}
:
: to iterate the junction.
For the purposes of S03 it would have been better to use an example
without list context like:
- $x {...}(all(@foo))
or maybe
all(@foo).each:{...}
I think that given specifically does not autothread it's block, so
given any(1,2,3) {...}
matches each case against any(1,2,3). That is, there is an MMD variant
of given that accepts a Junction, which disables autothreading.
Or maybe S03 really just wants to say that
if all(@foo).each:{...} {...}
is allowed to stop evaluating cases in random order when it gets
the first false value back from .each, while
if any(@foo).each:{...} {...}
is allowed to stop as soon as it gets a true value.
Larry
