Re: A proposition for streamlining Perl 6 development

[Yuval Kogman]

On Tue, Feb 07, 2006 at 23:11:32 -0800, Allison Randal wrote:
> On Feb 7, 2006, at 19:21, Stevan Little wrote:
> >>Perl 6 will get implemented.
> >Oh, of that I have no doubt. Never did, and neither does Yuval (if I
> >may speak for him while he is asleep :). But all that we are trying to
> >do here is shake out some cobwebs, a little spring cleaning if you
> >will.
> 
> Excellent. I wish you much fun! :)

Does this imply that we should think up this process?

If so, I have made many many contributions on this topic to
perl6-language on this topic, and I feel like they have been mostly
overlooked.

If I propose a concrete plan for the implementation of Perl 6 in a
layered fashion it will probably be even more overlooked.

I have no authority, and this is not something I can do on my own.

I am asking for your (all of you) help in clarifying the big void
in the middle - the design of the perl 6 runtime, not just
syntax/features.

What I'm suggesting is a start in this clarification - trying to
componentize the existing syntax/feature spec that we do have, so
tha the design of the runtime can be simplified and more
concrete/attainable.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me does not drink tibetian laxative tea: neeyah!



pgp7l1B9MmXgY.pgp
Description: PGP signature

Smart match table

[Robin Houston]

The table of smart matches in S4 has this:

...
Any Str   string equality  match if $_ eq $x
...
Any Rule  pattern matchmatch if $_ ~~ /$x/
...

By my (and Damian's) interpretation of the table, this means
that "string" ~~ /rule/ would be interpreted as testing the
*string equality* of its operands, rather than doing a pattern
match.

Clearly this is not the intention. Am I misreading the table,
or is there a mistake? If the latter, what is the correct
precedence order of the table entries?

The other thing that seems odd to me is that

  $foo ~~ $bar

where $foo and $bar are both references to Code<>, is defined
to be equal to (the truth value of) $bar(). This seems an
unnecessary violation of commutativity.

For Perl 5, I changed the relevant part of the table to
read

Any undef undefinedmatch if !defined $a
Any Regex pattern matchmatch if $a =~ /$b/
Code()  Code()results are equalmatch if $a->() eq $b->()
Any Code()simple closure truth match if $b->() (ignoring $a)
Num numish[!] numeric equality match if $a == $b
Any Str   string equality  match if $a eq $b
Any Num   numeric equality match if $a == $b

which retains commutativity in all cases. Of course it's
different in Perl 6, because the "dotted entries" like
.[number] and .method need to behave non-commutatively.
But is it really necessary for coderefs?

Is my implementation sufficiently in the spirit of the Perl 6
design?

Thanks for your thoughts.

Robin

Re: A proposition for streamlining Perl 6 development

[Yuval Kogman]

On Tue, Feb 07, 2006 at 18:51:03 -0500, David K Storrs wrote:

> So, to bring it down to brass tacks:  there are 5 big chunks (S15,  S16, S18, 
> S21, S23) that remain to be be written, a 6th (S08) that  needs to be written 
> but will 
> probably be fairly short, and 5 (S28,  S30-33) that need to be compiled out 
> of the mass of emails flying  through the lists.  I know that substantial 
> progress has been 
> in  defining the semantics of all of these topics, and I have the  impression 
> that it's mostly a question of wrapping up the last 5-20%  of each one, 
> compiling all the 
> data, and writing the Synopsis.
> 
> 
> I'd say that qualifies as light at the end of the tunnel indeed!

The point I was trying to raise is that the Synopses are a very
high level, top down angle on the language's design.

They have *NOTHING* about any implementation details like:

the design of the compiler

the design of the runtime

the design of the object space

The layers of Perl 6 (what is an optional module? what is a
macro (see also 'use')? what is the core essence of Perl 6?).

Except implying that these things will be implemented in Perl 6, and
will be somehow worked out.

Now, I have no objection to this - the Synopses are sort of like
requirement docs.

But we do need something that's between where parrot is today, and a
top down view of all of Perl 6 - and that's a lot of chunks.

What I'm trying to say is that letting the part in the middle grow
completely organically and ad-hoc is not a good thing, and that
the pugs developers really have no authority as to making design
decisions. We need those things to happen and they're getting
overlooked, and in my opinion the first step into this is
refactoring the design into several layers.

Bottom line - there's much more than 5 missing chunks in the design,
as I see it - designing the implementation is nontrivial.

Also, none of the synopses are really 100% complete - S12 does not
detail the meta model's methods and features, for example. The doc
explaining macros does not detail what the AST macros get (the
definition of the AST). Etc etc etc. These things are also important
to implementation, and amount to a huge chunk of code. If we can
layer this code, chunk it up, componentize it and make it clean we
we can implement it more easily.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me groks YAML like the grasshopper: neeyah!!



pgpLHOQziXsCg.pgp
Description: PGP signature

Re: A proposition for streamlining Perl 6 development

[Yuval Kogman]

On Wed, Feb 08, 2006 at 08:59:35 +0800, Audrey Tang wrote:
> On 2/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > If Audrey is willing, I think a correct new direction for pugs is to
> > try and separate the parts even more - the prelude is a mess right
> > now, many of it's part are duplicated across the backends, the
> > standard library that is mashed into the prelude, and into pugs core
> > itself, etc.
> 
> Er, of course I'm willing, that was exactly we've been moving toward
> in the recent weeks. :-)
> 
> Though an explicit Standard Library design -- as compared to Perl5's which was
> grown out gradually by the porters and CPAN folks -- is tricky, and I'm not
> yet ready for that, lacking a practical understanding of how module interfaces
> and roles can be applied to this diverse design space.

By standard library is i don't mean core modules - it's Perl 6's
perlfunc + some really critical pieces.

> So I will be focusing on Prelude (the part of the language that always gets
> loaded by default) refactoring as well as providing an OO core calculus that 
> can
> support this, and take advantage of the target VM's vast library instead of
> writing them in Perl 6, at least up until 6.2831 (the primary target
> VM is Perl 5,
> then Parrot, then JavaScript.)

Aye =)

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me wields bonsai kittens: neeyah



pgpvIhRiCE7cG.pgp
Description: PGP signature

Re: tokenizer hints, supporting delimited identifiers or symbols

[Larry Wall]

On Tue, Feb 07, 2006 at 03:54:07PM -0800, Larry Wall wrote:
: On Tue, Feb 07, 2006 at 03:28:05PM -0800, Larry Wall wrote:
: : say $::;
: 
: Or you can use a symbolic ref with a constant string:
: 
: $::('x y');
: 
: The compiler knows it's a constant.  And it's even implemented in Pugs.

Hmm, except you can't yet use the $::('') form in a "my", of course.
Presumably we'll have to tell "my" to accept one or another of these
quoting forms to avoid people scattering BEGIN blocks all over just so
they can introduce funny symbols into their MY tables.  Arguably you
ought to be able to say things like

my $::('foo') = 1;
my $:: = 2;

when the name can be resolved at compile time.

Anyway, however it works out, my point is that we don't need to recruit
a new quoting delimiter for it.  I think ` can still be reserved for
user-defined quoting.

Larry

Re: A proposition for streamlining Perl 6 development

[Allison Randal]

On Feb 7, 2006, at 19:21, Stevan Little wrote:



Perl 6 will get implemented.


Oh, of that I have no doubt. Never did, and neither does Yuval (if I
may speak for him while he is asleep :). But all that we are trying to
do here is shake out some cobwebs, a little spring cleaning if you
will.


Excellent. I wish you much fun! :)

Allison

Re: tokenizer hints, supporting delimited identifiers or symbols

[Larry Wall]

On Wed, Feb 08, 2006 at 12:26:52AM +, Luke Palmer wrote:
: On 2/7/06, Larry Wall <[EMAIL PROTECTED]> wrote:
: > $MY::{'x y'}
: > $MY::  # same thing
: > MY::<$x y>  # same thing
: 
: Er, aren't we obscuring the meaning of <> a little bit here?   I would
: think that the following two things would be equivalent:
: 
: $My::
: $My::{'x','y'}

Er, yeah.  My bad.

Larry

Re: A proposition for streamlining Perl 6 development

[Stevan Little]

On 2/7/06, Allison Randal <[EMAIL PROTECTED]> wrote:
> On Feb 7, 2006, at 15:31, Stevan Little wrote:
> >
> > Now I am not as involved in Parrot as I am in Pugs so I might be way
> > off base here, but from my point of view Parrot still has a long way
> > to go before it runs Perl 6 code. Part of that is because the bridge
> > between PIR/PMCs and Perl 6 just does not exist yet (either in code,
> > or even conceptually). Having PGE parse Perl 6 code only gives us an
> > AST, it does not give us running code. And even if we have a nicely
> > massaged AST, running Perl 6 is not a matter of just walking the tree
> > and evaluating it like it is in Perl 5 (of course, I am simplifying
> > quite a bit here). We found (a few months ago) in Pugs that this model
> > just isn't robust enough, and Perl 6 is going to need a more
> > sophisticated "runtime" environment to support many of it's features.
> > This "runtime" (or as we have been calling it in Pugs the "Object
> > Space") will need to exist on top of Parrot too since it is far to
> > Perl 6 specific to be implemented into the Parrot core.
> >
> > This is the kind of stuff that Yuval is talking about. The missing
> > bits that need to exist in the nether-region between perl6-language
> > and perl6-internals.
> >
> > We are building from the bottom-up (Parrot) and the top-down (Perl 6 -
> > the language) and it seems (at least to many of us on the Pugs
> > project) that there is a big hole somewhere in the middle.
>
> You imply here that obstacles to implementing Pugs are necessarily
> obstacles to implementing Perl 6. That's not entirely accurate.

Well, the first obstacle I see to implementing Perl 6 can be fixed
with the object space work, and I do not see the Perl 6 Object space
work as being Pugs specific at all. From work I and others have done
on the meta-model  as well as the container types, it seems clear that
we need a very robust Perl 6 runtime environment. And currently Parrot
does not provide enough of that environment. This is not to say that
Parrot *cannot*, only that it does not currently. And in my opinion,
Parrot shouldn't cater this much to Perl 6 anyway. Parrot's object
model is sufficently generic to support the object model of most of
the current crop of dynamic languages, but that will not be enough for
Perl 6. You just can't compile all the runtime dynamism into PIR and
PMCs, you will need a runtime environment (an object space) to support
it.

The next obstacle to implementing Perl 6 I see is the
type-checker/inferencer, this is not the job of Parrot, or of PGE. It
a the job for a type inferencer, of which I don't see work on one
currently outside of Pugs and Yuval's Blondie work.

Then there is the prelude. Why write Perl 6's built-ins in PIR when
you can write it in Perl 6? Assuming the Perl 6 codegen is good enough
of course. And modern compiler and optimization technology has been
doing those things since the late-80s (there are many studies of how
compiled Ada code was faster and better than expert hand coded
asssembler, there are just some things a computer can do better than a
person).

I think Pugs and Parrot/PGE share many more obstacles than you might think.

> But, there is another route, and we're working on it at the same
> time. From the Parrot perspective, PGE parses the source, its output
> is translated to an AST (or a couple of intermediate ASTs), and that
> is translated either to PIR, or directly to bytecode.

But this is my point, this won't be enough to support all that Perl 6
is to be. PIR & PMCs simply are not enough to have full metaclass
support, roles (at compile/class composition time, and runtime),
traits, etc. And lets not forget that (to quote Larry in S02 i think)
"Perl 6 is an OO engine". Which means that container types like
Scalars, Arrays and Hashes are objects now too. These things map
nicely to some of the current PMCs, but they are not boxed inside the
object metamodel, and until they are they are not extendable and
usable in the way the language design prescribes.

The Pugs project started out with an AST which was then evaluated,
which is similar to your AST translated to PIR, and we just found it
wasn't enough. Perl 6 is just simply to dynamic a language for that.

> I'm working on a prototype of this now in Punie, specifically so we can try 
> out the
> whole path from source code to bytecode.

I am familiar with your Punie work as I read your use.perl journal and
the Perl 6 meeting notes regularly. But IIRC Punie is a compiler for
Perl 1 is it not? Perl 1 is a very very very long way from Perl 6.

> Perl 6 will get implemented.

Oh, of that I have no doubt. Never did, and neither does Yuval (if I
may speak for him while he is asleep :). But all that we are trying to
do here is shake out some cobwebs, a little spring cleaning if you
will.

Stevan

Re: overloading the variable declaration process

[Stevan Little]

On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
> Stevan~
>
> On 2/7/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> >
> > Well, to be totally honest, I think only Larry truely understands
> > their usage, but to the best of my understanding they are intented to
> > serve a number of roles;
>
> I agree with you about that, which is part of what bothers me.
>
> >
> > (Larry, please correct me if I am wrong here)
> >
> > - to allow for introspection of the class.
> >
> > After all ^Foo.can() is really just a series of method calls to the
> > Foo metaobject. And besides ^Foo.meta.can() is 5 more characters to
> > type!!
> >
> > - provide an invocant for "class" methods.
> >
> > Larry does not like the class-method/instance-method distinction (in
> > fact it seems he doesn't even like the class/instance distinction
> > either), and has declared that a "class method" is really just a
> > method of the class which does not access any instance attributes.
> > Well, this complicates the type signature of the invocant, and we need
> > an invocant that the type-checker can check.
> >
> > In Perl 5, classes were just package names which were just strings.
> > This will not work in Perl 6 in the presence of a reasonably decent
> > type checker, the class needs to be *something*. Now Larry has also
> > declared  that he does not like the idea of a "class object", I think
> > this is because that means that a properly typed method signature for
> > a class method would look like this:
> >
> > class Foo {
> > method foo (Class $class:) {
> > say "I am a class method, and proud of it";
> > }
> > }
> >
> > According to the signature, this method takes any Class instance as an
> > invocant. Well
> > thats just not right because it should only accept the Class instance
> > which represents the Foo class. But we can't (at least I dont think we
> > can) be that specific, at least not easily enough to also allow this
> > method to be called by an instance of Foo as well.
> >
> > So, the solution,  use "prototype instances" for "class objects". So
> > now we can properly type our class method for both Foo and $foo like
> > this:
> >
> > class Foo {
> > method foo (Foo $class:) {
> > say "I am a class method, and proud of it";
> > }
> > }
> >
> > And whalla, we have a class/instance method ala Perl 5 and it is
> > properly type checkable too.
> >
> > Of course I might be totally wrong here, but this is my best grasp on
> > the subject.
>
> Perl 6 allows dispatch on value (if I am not mistaken).  Thus, just as we 
> have a
>
> sub fact( Int 0 ) { return 0; }
> sub fact( Int $n ) { return $n * fact($n-1); }
>
> Why not have class methods take the form
>
> class Foo {
> method foo (Class Foo) {
> say "I am a class method, and proud of it";
> }
> }
>
> They are still well types (I think), and properly restricts the types
> allowed for foo.

Larry is going to have to answer the why part of that descision.
However, I would venture to guess that dispatch on value is much
harder to grok in this case than dispatch on type. Especially since it
requires that you understand (at least partially) the metamodel.

> After all Foo is just a specific instance of the class Class.

Shhh... class objects don't exist ... I was never here,... I will I
count to three and when I snap my fingers you will awaken and will
have forgotten all about class Class.

1 ... 2 ... 3 ... *snap*

Re: overloading the variable declaration process

[Matt Fowles]

Stevan~

On 2/7/06, Stevan Little <[EMAIL PROTECTED]> wrote:
>
> Well, to be totally honest, I think only Larry truely understands
> their usage, but to the best of my understanding they are intented to
> serve a number of roles;

I agree with you about that, which is part of what bothers me.

>
> (Larry, please correct me if I am wrong here)
>
> - to allow for introspection of the class.
>
> After all ^Foo.can() is really just a series of method calls to the
> Foo metaobject. And besides ^Foo.meta.can() is 5 more characters to
> type!!
>
> - provide an invocant for "class" methods.
>
> Larry does not like the class-method/instance-method distinction (in
> fact it seems he doesn't even like the class/instance distinction
> either), and has declared that a "class method" is really just a
> method of the class which does not access any instance attributes.
> Well, this complicates the type signature of the invocant, and we need
> an invocant that the type-checker can check.
>
> In Perl 5, classes were just package names which were just strings.
> This will not work in Perl 6 in the presence of a reasonably decent
> type checker, the class needs to be *something*. Now Larry has also
> declared  that he does not like the idea of a "class object", I think
> this is because that means that a properly typed method signature for
> a class method would look like this:
>
> class Foo {
> method foo (Class $class:) {
> say "I am a class method, and proud of it";
> }
> }
>
> According to the signature, this method takes any Class instance as an
> invocant. Well
> thats just not right because it should only accept the Class instance
> which represents the Foo class. But we can't (at least I dont think we
> can) be that specific, at least not easily enough to also allow this
> method to be called by an instance of Foo as well.
>
> So, the solution,  use "prototype instances" for "class objects". So
> now we can properly type our class method for both Foo and $foo like
> this:
>
> class Foo {
> method foo (Foo $class:) {
> say "I am a class method, and proud of it";
> }
> }
>
> And whalla, we have a class/instance method ala Perl 5 and it is
> properly type checkable too.
>
> Of course I might be totally wrong here, but this is my best grasp on
> the subject.

Perl 6 allows dispatch on value (if I am not mistaken).  Thus, just as we have a

sub fact( Int 0 ) { return 0; }
sub fact( Int $n ) { return $n * fact($n-1); }

Why not have class methods take the form

class Foo {
method foo (Class Foo) {
say "I am a class method, and proud of it";
}
}

They are still well types (I think), and properly restricts the types
allowed for foo.  After all Foo is just a specific instance of the
class Class.

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

Perl 6 Summary for 2006-01-24 though 2006-02-07

[Matt Fowles]

Perl 6 Summary for 2006-01-24 though 2006-02-07
All~

Welcome to another fortnight's summary. I would say more, but my throat
really hurts.

  Perl 6 Language
   Pugs's Minimum GHC
Darren Duncan proposed moving the minimum GHS requirement from 6.4.0 to
6.4.1. Based on the conversation, this appears to be a somewhat likely
outcome.



   Pugs Makefile.PL Update
Beau E. Cox posted a patch to improve Makefile.PL. Audrey added it and
handed him a commit bit.



   Pugs 3.2.11
Pugs, now officially 1 year old, just hit its 6.2.11 release.



   Pugs Link Error
Beau E. Cox had trouble linking Pugs 6.2.11 and Parrot 0.4.1. Audrey
pointed out that he needed a parrot source tree nearby.



   Macros
Larry Wall posted an update of S06. It looks very tasty. I hope the
standard library has some convenience routines for dealing with Perl 6's
AST.



   Pugs Version Numbers
Beau E. Cox was a little confused by Pugs's jump in development version.
Kevin Puetz explained the approach to $2 \pi$.



   Parrot Source Tree for Pugs?
Beau E. Cox, after discovering that a Parrot source tree is necessary to
build Pugs, wondered if it was still necessary after Pugs was built.
Larry provided the answer: no.



   PGE Binding
Audrey noticed a problem convincing PGE to alias a scalar. Patrick
explained that it was not yet implemented.



  Parrot
Hmmm... If the short one required two cough drops, I fear for the long
one. Of course, that was uncharacteristically large for p6l, so perhaps
p6i will be short. (Gambler's Fallacy, I know)

   Namespace Relativism
Leo noticed a few namespace opcodes which could function either
relatively or absolutely. Peoples seemed to want absolute.



   Interpreters and Stashes?
Leo posted a few questions about parts of Parrot's guts that he wasn't
sure about. Chip posted his thoughts.



   File, OS, and Path
Alberto Simões posted his proposal for File/OS functions. Chip provided
his opinions as well.



   Object Initialization Issues
Bob Rogers noticed a change in the semantics of object initialization.
He and Leo added tests and nailed down them down more firmly.



   I/O Filters
Steve Gunnell posted his ideas for how to finalize and improve the I/O
filter system on which Parrot's IO is built. Leo, Nicholas Clark, and
Joshua Hoblitt fined tuned his ideas slightly.



   Parrot on z/OS
Ravi Sastry wondered if Parrot could run on z/OS. Jonathan Worthington
guessed that it probably would not run right now, but could be made to
run by an interested developer.



   Dirty I Registers
Jerry Gay noticed that IREGs weren't being zeroed properly.



   Parrot::Configure::Data::Bug
Norman Nunley found and fixed a bug in Parrot::Configure::Data. Leo
applied the patch.



   PARROT_IN_EXTENSION
Nicholas Clark noticed some macro strangeness involving
PARROT_IN_EXTENSION. Jonathan Worthington determined that it was
vestigial and remove it. Nicholas was happy.



   Invalid Cleaning Order
Bernhard Schmalhofer noticed that "make clean" was cleaning itself into
a corner. He filed a bug for it.



   FreeBSD JIT Bug
Joshua Isom found a problem with the FreeBSD JIT. Leo pointed him to
some docs to help him debug his problem.



   Makefile Cleanup
Joshua Isom posted a patch cleaning up some makefile stuff. Joshua
Hoblitt thought that further review was necessary. Warnock applies.



   Supporting Static Variables
Leo posted a few thoughts on how to support static variables in Parrot.
Larry, Nicholas Clark, and Joshua Isom provided a few suggestions.



   Truncating Generated PIR Code
Allison Randal was having problems with generated PIR code getting
truncated. Leo managed to track down and solve the problem.



   Want a Job?
[EMAIL PROTECTED] posted a job offering to the list. Unfortunately
he posted it to google groups (most likely) as it didn't make it to the
list proper.



   Exception in a Constructor Oddness
Jonathan Worthington provided a test case display an unexpected
interaction between constructors and exceptions. Warnock applies.



   Continuation Return Values
Bob Rogers provided a patch allowing Continuations to return values. Leo
applied the patch.



   Dynamic PMC Link D

Re: A proposition for streamlining Perl 6 development

[Stevan Little]

On 2/7/06, chromatic <[EMAIL PROTECTED]> wrote:
> On Tuesday 07 February 2006 15:56, Stevan Little wrote:
>
> > The Pugs project and the Parrot project have had very different goals
> > actually (at least Pugs did from the early days). Pugs aimed to be
> > able to evaluate Perl 6 code, as a way of testing the language
> > features and design. It did not really attempt (until the PIL work
> > began) to provide a VM for Perl 6 to run on.
>
> In my mind, that's the most valuable thing Pugs could do.

Well, a few months ago I would have disagreed, but now I agree with
you, by taking this down the VM level (which is that the PIL^N/PIL2
runcore is focusing on) is good "research" for eventually connecting
this all to Parrot.

I am glad we agree here.

>
> > And even the PIL work began as a way to strip Perl 6 down to a more
> > managable core calculus which was easier to interpret, the multiple backends
> > seemed to grow out of that as a side-effect.
>
> But they're not free to support.

Well yes that is very true, but that was a learning process. It helped
uncover some of the deficencies in the first PIL implementation (most
notable the lack of OO support). It also lead to the development of
the Object Space sub-project which is aiming to clarify how we get
from Perl 6 to something that is executable in an environment which
supports all the features designed.

These are both things which the Parrot project and the Perl 6 design
project did not address from what I can see. Only after going down
some highly experimental paths did this reveal itself.

So while I agree, they are not free to support, I would argue that
they are R&D prototypes and so (to some degree) disposable, and the
benefits they have brought in terms of insight into Perl 6 "the
runtime" (not the language, and not the VM, but somewhere in between)
are very vaulable.

> Now I'm not arguing that the existence of multiple backends takes effort away
> from a single unified backend.  This is open development.  People work on
> what they want to work on.

Exactly Yuval's point. People want something interesting enough to
pique their interest, but small enough to digest for weekend/nighttime
hacking sessions. If Perl 6 was broken down in such a way as he
proposes, maybe it would attrack more people? or maybe it won't.
Neither I or you knowt that, we can only guess.

> Still, finding the greatest common factor of features between LLVM, Scheme,
> Spidermonkey, classic Pugs, Parrot, the CLR, the JVM, Perl 5, and whatever
> other VM is out there means pushing a lot of things up the implementation
> stack.

Sure that's one way to look at it, but it does not need to be that
way. Reducing Perl 6 down to a core calculus like PIL actually makes
it easier to target any backend you want. And the new PIL^N/PIL2
runcore will make it even easier since all that will be required will
be that you create a PIL^N runtime, all the
metamodel/container/boxed-type prelude will either be written in PIL^N
or in Perl 6. Then the Perl 6 -> PIL2 part can be written using
PGE/TGE/Parsec/whatever.

IMHO this design direction (which makes multiple backends almost
trivial) makes for a better more modular and decoupled design in
general, which is surely a good thing for all projects involved
including Parrot.


> > Much of what Yuval is proposing is ways to fill that hole and to
> > decompose and refactor the current Perl 6 development process so that
> > we can have a real production Perl 6 to play with that much sooner.
>
> I agree that that's his goal.  I disagree on its appropriateness.

What is inappropriate about it? He is questioning the current
direction of an open source project which has be regarded as many to
be mearly vaporware. Sure you and I know that Perl 6 is chugging right
 along and making great strides, but until Pugs many people considered
Perl 6 to be a joke at best, and total vaporware at worst.

I think Yuval has every right to question the direction, and to make
suggestions as to how he thinks it can be improved upon. He has put in
time on the project, maybe not as much as others, but enough that I
think he has a right to speak up if he wants. What is so wrong with
that?

> There are people who can write a bootstrapping compiler from the top down in
> such a way that normal people can write the user-level primitives in that
> language.  I've met those people.  I'm not one of them.  There are precious
> few of them for any language, much less Perl 6.

Hmm, quite true, but I think that is mostly because the texts on the
subject are so dense and there is a severe lack of hackable projects
out there that people can contribute too that don't involve some
esoteric language meant to explore some equally esoteric concept.

However, that said, the idea of bootstrapping compilers is
progressively getting more mainstream. Many of the recent languages 
which have sprung up for the CLR are moving towards bootstrappability.
The new version of Scala is written in Scala. So may

Re: A proposition for streamlining Perl 6 development

[Allison Randal]

On Feb 7, 2006, at 15:31, Stevan Little wrote:


Now I am not as involved in Parrot as I am in Pugs so I might be way
off base here, but from my point of view Parrot still has a long way
to go before it runs Perl 6 code. Part of that is because the bridge
between PIR/PMCs and Perl 6 just does not exist yet (either in code,
or even conceptually). Having PGE parse Perl 6 code only gives us an
AST, it does not give us running code. And even if we have a nicely
massaged AST, running Perl 6 is not a matter of just walking the tree
and evaluating it like it is in Perl 5 (of course, I am simplifying
quite a bit here). We found (a few months ago) in Pugs that this model
just isn't robust enough, and Perl 6 is going to need a more
sophisticated "runtime" environment to support many of it's features.
This "runtime" (or as we have been calling it in Pugs the "Object
Space") will need to exist on top of Parrot too since it is far to
Perl 6 specific to be implemented into the Parrot core.

This is the kind of stuff that Yuval is talking about. The missing
bits that need to exist in the nether-region between perl6-language
and perl6-internals.

We are building from the bottom-up (Parrot) and the top-down (Perl 6 -
the language) and it seems (at least to many of us on the Pugs
project) that there is a big hole somewhere in the middle.


You imply here that obstacles to implementing Pugs are necessarily  
obstacles to implementing Perl 6. That's not entirely accurate. The  
bootstrapping Perl 6-on-Perl 6 architecture does require a high  
degree of abstraction. The choice of architecture means there's a  
greater gap to fill between the abstraction and the core  
implementation. This was my original objection to Pugs, but I changed  
my mind. You all have demonstrated incredible skill and energy over  
the past year, and I'm confident you will figure out a way to do it.


But, there is another route, and we're working on it at the same  
time. From the Parrot perspective, PGE parses the source, its output  
is translated to an AST (or a couple of intermediate ASTs), and that  
is translated either to PIR, or directly to bytecode. I'm working on  
a prototype of this now in Punie, specifically so we can try out the  
whole path from source code to bytecode.


Perl 6 will get implemented.

Allison

Re: A proposition for streamlining Perl 6 development

[Audrey Tang]

On 2/8/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> If Audrey is willing, I think a correct new direction for pugs is to
> try and separate the parts even more - the prelude is a mess right
> now, many of it's part are duplicated across the backends, the
> standard library that is mashed into the prelude, and into pugs core
> itself, etc.

Er, of course I'm willing, that was exactly we've been moving toward
in the recent weeks. :-)

Though an explicit Standard Library design -- as compared to Perl5's which was
grown out gradually by the porters and CPAN folks -- is tricky, and I'm not
yet ready for that, lacking a practical understanding of how module interfaces
and roles can be applied to this diverse design space.

So I will be focusing on Prelude (the part of the language that always gets
loaded by default) refactoring as well as providing an OO core calculus that can
support this, and take advantage of the target VM's vast library instead of
writing them in Perl 6, at least up until 6.2831 (the primary target
VM is Perl 5,
then Parrot, then JavaScript.)

But if you'd like to work on the standard library -- well, you have a
commit bit. :-)

Audrey

The definition of 'say'

[Robin Houston]

Late last year I implemented a few Perl 6 features in Perl 5.
A couple of things have emerged that may be relevant to the
Perl 6 design. Certainly they're things that I'm curious about.
I'll send the other one in a separate message to keep the
threads apart: this message is about 'say'.

The definition of 'say' is very simple:

  say 

is exactly equivalent to

  print , "\n"

and that's just the way it works in Perl 5.9.3. In fact,
that's how it's compiled. A few people on p5p have expressed
some disquiet that

  say "foo";

will print the string "foo$,\n$\". I'm inclined to agree that
this seems sensible only when $, and $\ are both empty, as
they are by default.

I'm not sure what the Perl 6 analogues are of $, and $\. I've
heard that $\ is a per-filehandle setting. Is there any analogue
of $,? Presumably there is.

In short, I'm curious as to why say is defined as it is, rather
than, for example, to be the equivalent of the Perl 5 code

  { local $\ = "\n"; print  }

I've searched the archives of this list, but failed to turn
up anything relevant.

Cheers,

Robin

Re: overloading the variable declaration process

[Stevan Little]

On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
> Stevan~
>
> I am going to assume that you intended to reply to perl 6 language,
> and thus will include your post in its entirety in my response.

Yes, sorry... I missed the "reply to all" button on the gmail UI by a
few pixels I guess. Thank you for forwarding.

> Now that everyone is on the same page, I will go about responding
>

# snip some code 

> >
> > class Pipe::Stem {
> >has $composed_of;
> >has $color;
> >has $length;
> >has $filter = bool::false;
> > }
>
> so far I am mostly with you, except one question.  Does  bool::false;> just provide a default?

Yes, that is a default value. I assume that most Pipe smokers don't
like filters in their pipes, I might be wrong on that one because I am
not a pipe smoker :)

> > You would then model the different pipes you sell;
> >
> > class MagrittePipe {
> > has $stem = Pipe::Stem.new(
> >  :composed_of,
> >  :color,
> >  :length
> >  );
> > has $bowl = Pipe::Bowl.new(
> >  :composed_of,
> >  :color,
> >  :size
> >  );
> > }
> >
> > Now, you might say, why not make the MagrittePipe an instance of Pipe,
> > and give the Pipe class a few more attributes, like a name. Well, if
> > you did that then you couldn't subclass it of course.
>
> Actually, I was going to ask why not make MagrittePipe inherit from Pipe.

Ooops, forgot that part it should infact inherit from Pipe. And of
course you can do that dynamically with the metamodel ;)

> > Well, using introspection, it becomes very simple to discover various
> > qualities about your inventory, enough to probably even autogenerate
> > the HTML pages for your online-web store (powered by Perl 6 of
> > course). And lets not forget the uber-cool Perl 6 Object Database
> > which you are using to store your real-time inventory in (all
> > metamodel powered of course). And of course if you want, you can use
> > the DistributedObjectProxy metaclass which will automatically make
> > your objects distributed so that your door-to-door Pipe saleforce can
> > update your inventory in real time from their cellphones. And your R&D
> > department can use the built-in (but as yet unspeced) logic
> > programming features of Perl 6 to mine your customer information from
> > your (previously mentioend) object database and genetically "grow"
> > new, more desireable Pipe products (which is easy to do since your
> > metaclasses are programatically composable (and no I don't mean eval
> > $code)).
>
> I think you mis-understand me.  I do not question the value of a
> powerful meta-model.  Quite the contrary I want to see Perl 6 have a
> meta-model more powerful and accessible then CLOS.  I see it as a
> necessity for a language that plans to truely scale in the future.
>
> What I do question is the usefullness of having bare class names
> represent these "prototype objects".  I just don't really understand
> what they are for or do.

Well, to be totally honest, I think only Larry truely understands
their usage, but to the best of my understanding they are intented to
serve a number of roles;

(Larry, please correct me if I am wrong here)

- to allow for introspection of the class.

After all ^Foo.can() is really just a series of method calls to the
Foo metaobject. And besides ^Foo.meta.can() is 5 more characters to
type!!

- provide an invocant for "class" methods.

Larry does not like the class-method/instance-method distinction (in
fact it seems he doesn't even like the class/instance distinction
either), and has declared that a "class method" is really just a
method of the class which does not access any instance attributes.
Well, this complicates the type signature of the invocant, and we need
an invocant that the type-checker can check.

In Perl 5, classes were just package names which were just strings.
This will not work in Perl 6 in the presence of a reasonably decent
type checker, the class needs to be *something*. Now Larry has also
declared  that he does not like the idea of a "class object", I think
this is because that means that a properly typed method signature for
a class method would look like this:

class Foo {
method foo (Class $class:) {
say "I am a class method, and proud of it";
}
}

According to the signature, this method takes any Class instance as an
invocant. Well
thats just not right because it should only accept the Class instance
which represents the Foo class. But we can't (at least I dont think we
can) be that specific, at least not easily enough to also allow this
method to be called by an instance of Foo as well.

So, the solution,  use "prototype instances" for "class objects". So
now we can properly type our class method for both Foo and $foo like
this:

class Foo {
method foo (Foo $class:) 

Re: A proposition for streamlining Perl 6 development

[chromatic]

On Tuesday 07 February 2006 15:56, Stevan Little wrote:

> The Pugs project and the Parrot project have had very different goals
> actually (at least Pugs did from the early days). Pugs aimed to be
> able to evaluate Perl 6 code, as a way of testing the language
> features and design. It did not really attempt (until the PIL work
> began) to provide a VM for Perl 6 to run on.

In my mind, that's the most valuable thing Pugs could do.

> And even the PIL work began as a way to strip Perl 6 down to a more 
> managable core calculus which was easier to interpret, the multiple backends 
> seemed to grow out of that as a side-effect.

But they're not free to support.

Now I'm not arguing that the existence of multiple backends takes effort away 
from a single unified backend.  This is open development.  People work on 
what they want to work on.

Still, finding the greatest common factor of features between LLVM, Scheme, 
Spidermonkey, classic Pugs, Parrot, the CLR, the JVM, Perl 5, and whatever 
other VM is out there means pushing a lot of things up the implementation 
stack.

> Much of what Yuval is proposing is ways to fill that hole and to
> decompose and refactor the current Perl 6 development process so that
> we can have a real production Perl 6 to play with that much sooner.

I agree that that's his goal.  I disagree on its appropriateness.

There are people who can write a bootstrapping compiler from the top down in 
such a way that normal people can write the user-level primitives in that 
language.  I've met those people.  I'm not one of them.  There are precious 
few of them for any language, much less Perl 6.

It's not fast.  It's not free.  It's not clear that they'll suddenly appear to 
do this work if there's a comprehensive, intelligible rework of the Perl 6 
plan.

I could be wrong and if Yuval writes the plan and it works, great!  I'm happy 
to be wrong.

> But also have a Perl 6 that some PhD canidate can re-write the
> type-checker for his thesis project or that some volunteer hobbiest
> can re-implement the core in FORTH or some open source hacker can hack
> the circular prelude to make the Schwartzian transformation that much
> quicker and efficient.

Again, I can see the theoretical benefit to that, but it's still not free.

The well-worn adage is "Good, fast, or cheap -- pick two."  Perl 6 development 
right now is cheap but hopefully good.  Reducing the goodness might make it 
faster.  Reducing the cheapness might too.  I think the real problem is 
somewhere in there.

> IMHO breaking down the project into smaller more digestable chunks
> carries as much risk of failure as putting all the eggs into single
> Parrot nest.

Exactly how is Yuval's proposal making the chunks more digestible?  There's 
sort of a dearth of Scheme, CLOS, Haskell, and Scala experts in Perl 6 
development right now.  Where are they going to come from to write all this 
stuff?

-- c

Re: tokenizer hints, supporting delimited identifiers or symbols

[Luke Palmer]

On 2/7/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> $MY::{'x y'}
> $MY::  # same thing
> MY::<$x y>  # same thing

Er, aren't we obscuring the meaning of <> a little bit here?   I would
think that the following two things would be equivalent:

$My::
$My::{'x','y'}

Luke

Re: tokenizer hints, supporting delimited identifiers or symbols

[Larry Wall]

On Tue, Feb 07, 2006 at 03:49:36PM -0800, Darren Duncan wrote:
: At 3:28 PM -0800 2/7/06, Larry Wall wrote:
: >say $::;
: >Larry
: 
: My mistake.  When I read Synopsis 2 I had interpreted the text more 
: narrowly than what I was looking for.  So for now I retract my 
: request.

Well, it's not like any of the Synopses are the height of clarity.
But that's okay--we're applying XP to the design process in the hopes
that just roughing it in and patching things up as we go along is
faster than trying to specify it all in advance.  We're not trying
to design another Ada here...

But yes, there is a mechanism specified for doing hash lookups on
particular symbol tables, and the intent whenever hash subscripting
pops up is that it be orthogonal to whether you use .{'x y'} or ..

Larry

Re: A proposition for streamlining Perl 6 development

[Stevan Little]

On 2/7/06, chromatic <[EMAIL PROTECTED]> wrote:
> On Tuesday 07 February 2006 14:17, Yuval Kogman wrote:
> > De-facto we have people running PIL on javascript.
> > It works more than parrot does.
>
> No, it works *differently* from Parrot, just as an LR parser works differently
> from an LR parser.
>
> Don't make the mistake of thinking "Wow, it took Parrot X months to get a
> working PGE, while the Pugs version only took Y weeks", especially because
> the Pugs version had the benefit of looking at *already designed, debugged,
> and tested* Parrot code.

The Pugs project and the Parrot project have had very different goals
actually (at least Pugs did from the early days). Pugs aimed to be
able to evaluate Perl 6 code, as a way of testing the language
features and design. It did not really attempt (until the PIL work
began) to provide a VM for Perl 6 to run on. And even the PIL work
began as a way to strip Perl 6 down to a more managable core calculus
which was easier to interpret, the multiple backends seemed to grow
out of that as a side-effect.

So I guess what i am saying is that I agree with you, comparing Pugs
development to Parrot development does not make sense. However, I
think we arrive at that conclusion from different angles.

It seems to me that Pugs has taken a top-down (more language centric)
approach, and Parrot has taken a more bottom-up (runtime/VM centric
approach), and in my eyes, there is a big gapping hole in the middle
(see my response to Allison's post for details about the "big gapping
hole").

Much of what Yuval is proposing is ways to fill that hole and to
decompose and refactor the current Perl 6 development process so that
we can have a real production Perl 6 to play with that much sooner.
But also have a Perl 6 that some PhD canidate can re-write the
type-checker for his thesis project or that some volunteer hobbiest
can re-implement the core in FORTH or some open source hacker can hack
the circular prelude to make the Schwartzian transformation that much
quicker and efficient.

IMHO breaking down the project into smaller more digestable chunks
carries as much risk of failure as putting all the eggs into single
Parrot nest.

At the very least, this is a debate worth having, especially since we
have all been waiting very patiently for so many years now.

Once again...

Respectfully,

Stevan

Re: overloading the variable declaration process

[Matt Fowles]

Stevan~

I am going to assume that you intended to reply to perl 6 language,
and thus will include your post in its entirety in my response.

On 2/7/06, Stevan Little <[EMAIL PROTECTED]> wrote:
> On 2/7/06, Matt Fowles <[EMAIL PROTECTED]> wrote:
> > Larry~
> >
> > On 2/7/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> > >
> > > Indeed, and the modeling point of view is that $pipe is *also* just
> > > a representation of the Pipe.  Neither Pipe nor $pipe is the thing
> > > itself.  Most computer programs are about Something Else, so computer
> > > languages should be optimized for talking about other things rather
> > > than talking about themselves.  The answer to
> > >
> > > Pipe.can("Smoke")
> > > $pipe.can("Smoke")
> > >
> > > should be the same, not different.  On the other hand,
> > >
> > > ^Pipe.can("Smoke")
> > >
> > > is a different matter, insofar as you're asking a question about a Class
> > > object rather than a Pipe object.  And now you get your Platonism back.
> > > You just have to be explicit about it.
> >
> > I see the value of ^Pipe and $pipe as seperate objects which can be
> > manipulated programmatically.  What I don't really understand is what
> > exactly Pipe is and where it would be useful.
> >
> > They way you have described Pipe feels a little muddy to me and I am
> > unsure about its purpose and semantics.  Is it just an object I ask
> > `.can()` or does it have some deeper usefulness?
>
> Well since ^Pipe will really just be the same value as Pipe.meta, then
> you can do many things with it (if I get my metamodel wishes that is).
>  Now, in keeping with the "examples of useful things for people other
> than programmers and computers" spirit of this discussion, here is one
> possible approach to using metaclasses in a constructive way.
>
> Okay, so lets assume you own a tobacco shop, and you have modeled a
> Pipe hierarchy to represent all the pipes you sell. Your base classes
> might look something like this:
>
> class Pipe {
> has $stem;
> has $bowl;
> }
>
> class Pipe::Bowl {
>has $composed_of;
>has $color;
>has $size;
> }
>
> class Pipe::Stem {
>has $composed_of;
>has $color;
>has $length;
>has $filter = bool::false;
> }
>
> You would then model the different pipes you sell;
>
> class MagrittePipe {
> has $stem = Pipe::Stem.new(
>  :composed_of,
>  :color,
>  :length
>  );
> has $bowl = Pipe::Bowl.new(
>  :composed_of,
>  :color,
>  :size
>  );
> }
>
> Now, you might say, why not make the MagrittePipe an instance of Pipe,
> and give the Pipe class a few more attributes, like a name. Well, if
> you did that then you couldn't subclass it of course.
>
> class MagrittePipe::SpecialEngravedAnniversayEdition {
>  is MagrittePipe;
>  does Engraved[$engraving_text = "Ceci n'est pas une pipe"];
>  does SpecialEdition[$type];
> }
>
> Now, what does all this have to do with metamodel?
>
> Well, using introspection, it becomes very simple to discover various
> qualities about your inventory, enough to probably even autogenerate
> the HTML pages for your online-web store (powered by Perl 6 of
> course). And lets not forget the uber-cool Perl 6 Object Database
> which you are using to store your real-time inventory in (all
> metamodel powered of course). And of course if you want, you can use
> the DistributedObjectProxy metaclass which will automatically make
> your objects distributed so that your door-to-door Pipe saleforce can
> update your inventory in real time from their cellphones. And your R&D
> department can use the built-in (but as yet unspeced) logic
> programming features of Perl 6 to mine your customer information from
> your (previously mentioend) object database and genetically "grow"
> new, more desireable Pipe products (which is easy to do since your
> metaclasses are programatically composable (and no I don't mean eval
> $code)).
>
> Of course, I am just dreaming here, but  maybe I am not! Most of
> this is already possible using CLOS (see the Franz's AllegroCL 8.0
> it's bad*ss IMO), so why can't we have it?
>
> Anyway, I hope that doesn't make your head hurt too much Matt ;)

Now that everyone is on the same page, I will go about responding

> class Pipe {
> has $stem;
> has $bowl;
> }
>
> class Pipe::Bowl {
>has $composed_of;
>has $color;
>has $size;
> }
>
> class Pipe::Stem {
>has $composed_of;
>has $color;
>has $length;
>has $filter = bool::false;
> }

so far I am mostly with you, except one question.  Does  just provide a default?

>
> You would then model the different pipes you sell;
>
> class MagrittePipe {
> has $stem = Pipe::Stem.new(
>  :composed_of,
>  :color,
>   

Re: A proposition for streamlining Perl 6 development

[David K Storrs]

On Feb 7, 2006, at 6:51 PM, David K Storrs wrote:



I'd say that qualifies as light at the end of the tunnel indeed!



Forgot to say...all of this was was predicated on the idea that the  
code can't really be written until the spec is done.  Once the spec  
is complete (even if not totally frozen), it becomes much easier to  
produce the code.  Also, simply having the complete spec is a pretty  
major milestone that would be worth a lot of "spirit uplifting" points.



--Dks

Re: tokenizer hints, supporting delimited identifiers or symbols

[Larry Wall]

On Tue, Feb 07, 2006 at 03:28:05PM -0800, Larry Wall wrote:
: say $::;

Or you can use a symbolic ref with a constant string:

$::('x y');

The compiler knows it's a constant.  And it's even implemented in Pugs.

But my thinking on the ::<> form is that it derives from the symbol
table as hash forms:

$MY::{'x y'}
$MY::  # same thing
MY::<$x y>  # same thing

$GLOBAL::{'x y'}
$GLOBAL::  # same thing
GLOBAL::<$x y>  # same thing

but I was assuming some particular symbol table would be supplied if you
just specified a null symbol table, MY maybe.  If not, then you'd have
to say

$MY::

or use the symblic ref form.

Or I suppose the null symbol table could mean to search each symbol
table in the same order you would for a bare $foo.  In other words,
there would be no difference between $foo and $:: and ::<$foo>
(except you can't interpolate the last one in a string directly).

Larry

Re: A proposition for streamlining Perl 6 development

[David K Storrs]

On Feb 7, 2006, at 5:33 PM, Allison Randal wrote:

Parrot, on the other hand, has noticeably gained momentum the past  
6 months or so. AFAICT, this is largely due to the fact that we're  
close enough to finished that we can see the light at the end of  
the tunnel, and because Pugs reminded us to hold on to our sense of  
fun.



First off, I'm just a lurker on the lists and I don't spend tuits  
hacking Perl6, Parrot, or pugs.  Also, I'm definitely behind on the  
SOTA as far as P6 goes so, hopefully, nothing that I say below is  
outright wrong.  If it is, apologies.




I know that, over the last year or so, I've been feeling fairly  
exhausted with Perl6--as all large projects do, it takes a long time  
and, while it's going on, it's hard to see the progress that is being  
made.  I follow the lists, but I haven't done any Parrot or pugs  
hacking, so I didn't really have a practical sense of where things  
stood.  It seemed like a never ending treadmill, and I've been  
reading the lists in a more and more casual way as tuits and energy  
flag.


Well, after this exchange I decided to check out the state of things,  
and I was very pleasantly surprised.  IIRC, $Larry said that he would  
define the language in terms of the chapters from the Camel book,  
with the Synopses being the definitive version of the AES triad for a  
particular chapter.  So, here are the Synopses that are written and  
in the repository at https://svn.perl.org/perl6/doc/trunk/design/syn/


# S01.pod
# S02.pod
# S03.pod
# S04.pod
# S05.pod
# S06.pod
# S07.pod	Not actually here because formats have been removed, but  
I'm including it in the "complete" section.

# S09.pod
# S10.pod
# S11.pod
# S12.pod
# S13.pod
# S17.pod   Not complete, just lists topics to cover
# S29.pod   Not complete, just a pointer to


So, if @Larry precisely followed the Camel, here's what's left  
(sorted by my opinion of its likelihood of being written):


Synopsis
Topic   
Will it be written? (Just IMO)
	--- 
   -

S14.pod Tied variables   ?
S25.pod		Portable  
Perl  Maybe--probably  
just a tweak of P5 version
S19.pod		The  
CLI
Probably not
S20.pod		The Debugger
Probably not
S22.pod		 
CPAN   
Probably not
S26.pod		 
POD  
Probably not

S24.pod Common Practices   No
S27.pod		Perl  
CultureNo
S08.pod		 
ReferencesYes
S15.pod		 
Unicode  Yes
S16.pod		 
IPC
Yes
S18.pod		 
Compiling   Yes

S21.pod Internals and ExternalsYes
S23.pod		 
Security   Yes

S28.pod Reference; Special Names Yes
S30.pod Reference; The Standard Perl Library  Yes
S31.pod Reference; Pragmatic Modules  Yes
S32.pod Reference; Standard ModulesYes
S33.pod Reference; Diagnostic Messages  Yes

My reasoning:

	- S14: I'm not clear on whether tied variables have gone the way of  
formats.


	- S25: "Portable Perl", it's unclear how much the elements addressed  
therein would change from Perl5 to Perl6, so it might not be  
necessary to rewrite this beyond a few tweaks to the P5 version (like  
deleting the section on XS).


	- The ones labelled "Probably not" are (arguably) not properly part  
of the language but part of the toolkit around it.  As such, they  
don't really need to be included in the language spec.  YMMV.


	- S24: There can't really be any "Common Practices" until some time  
after 6.0.0 is released, so that's a No.


- S25: Perl Culture is definitely not part of the language design.

	- S08: More and more elements are being given first-class status and  
auto-referencing behaviors.  Once something is first-class and can  
smartly manage its own (de)referencing, there is no real need for  
user-level operators to do it.  However, we still need defined  
semantics for how it all works under the hood, so we need a Synopsis.


	- S15, S16, S18, S21, S23:  I thought these were a pretty clear call  
for "gotta have a spec".


	- S28, S30-33: The Reference Synopses are "simply" compilations of  
information that is designed elsewher

Re: tokenizer hints, supporting delimited identifiers or symbols

[Darren Duncan]

At 3:28 PM -0800 2/7/06, Larry Wall wrote:

say $::;
Larry


My mistake.  When I read Synopsis 2 I had interpreted the text more 
narrowly than what I was looking for.  So for now I retract my 
request.


Pugs still doesn't implement what you indicated though, from my 
testing, so I think I'll have to check that a test for the feature 
exists, and add one if not.


-- Darren Duncan

Re: A proposition for streamlining Perl 6 development

[Stevan Little]

On 2/7/06, Allison Randal <[EMAIL PROTECTED]> wrote:
> On Feb 7, 2006, at 13:28, Yuval Kogman wrote:
>
> > Apologies if this is insulting to anyone, but personally I think
> > that Perl 6 (pugs, parrot, everything) is losing too much momentum
> > lately. I think we need to seriously rethink some of the
> > implementation plan.
>
> I understand your frustration. I even sympathize, as I had to work
> through this same frustration a few years ago. But, micromanagement
> is not the answer to lost momentum.

I really don't think that Yuval is talking about micromangement. He is
talking about refactoring. I think we can all agree that:

- Small methods are good
- Monolithic God objects are bad

Decomposing the problem into smaller and smaller problems until the
problems become manageable for a small team of volunteers to work on
and understand.

> It actually makes things worse,
> as people throw their effort into defining the problem more and more
> clearly, instead of throwing their effort into producing shippable code.

I am not sure if that is Yuval's point either, in fact I think his
point is that without defining the problem a little clearer it will be
very difficult to actually produce shippable code.

> If it makes you feel any better, pretty much all projects suffer a
> loss of momentum after the first year.

Well I dont know about Yuval, but that depresses me somewhat :(

> Parrot, on the other hand, has noticeably gained momentum the past 6
> months or so. AFAICT, this is largely due to the fact that we're
> close enough to finished that we can see the light at the end of the
> tunnel, and because Pugs reminded us to hold on to our sense of fun.

Now I am not as involved in Parrot as I am in Pugs so I might be way
off base here, but from my point of view Parrot still has a long way
to go before it runs Perl 6 code. Part of that is because the bridge
between PIR/PMCs and Perl 6 just does not exist yet (either in code,
or even conceptually). Having PGE parse Perl 6 code only gives us an
AST, it does not give us running code. And even if we have a nicely
massaged AST, running Perl 6 is not a matter of just walking the tree
and evaluating it like it is in Perl 5 (of course, I am simplifying
quite a bit here). We found (a few months ago) in Pugs that this model
just isn't robust enough, and Perl 6 is going to need a more
sophisticated "runtime" environment to support many of it's features.
This "runtime" (or as we have been calling it in Pugs the "Object
Space") will need to exist on top of Parrot too since it is far to
Perl 6 specific to be implemented into the Parrot core.

This is the kind of stuff that Yuval is talking about. The missing
bits that need to exist in the nether-region between perl6-language
and perl6-internals.

We are building from the bottom-up (Parrot) and the top-down (Perl 6 -
the language) and it seems (at least to many of us on the Pugs
project) that there is a big hole somewhere in the middle.

Now, I am perfectly willing to admit that I am totally wrong and eat
every single one of my words if you can show me the missing conceptual
bridge that I am talking about. And please, no hand-waving as that
does not produce shippable code.

Respectfully,

Stevan

Re: tokenizer hints, supporting delimited identifiers or symbols

[Larry Wall]

say $::;

Larry

tokenizer hints, supporting delimited identifiers or symbols

[Darren Duncan]

All,

I would like for there to be a simple and terse way for Perl 6 
identifiers or symbols, including variable and subroutine and 
identifier names, to be able to be composed of any characters 
whatsoever, even whitespace, as it is possible to do in some other 
languages like SQL, and as it is possible to name filesystem files.


I also want to emphasize that what I'm looking for is simply a 
compile time feature; the delimited identifiers are always literal 
constants resolvable at compile time, so there is no possible 
deferral to runtime like with symbolic references that can come from 
variables.


This would asist in having closer mapping when porting code from a 
language like PLSQL to Perl, or invoking code in such languages, but 
also gaining that native ability internally.  And simply remapping 
characters, like spaces to underscores, won't work partly because of 
clashes like if the source had both a "the var" and a "the_var" 
already.  And certain other workarounds, like hex-escaping all source 
identifiers, would cause obfuscation, which is bad for understanding 
the result.


In a way, this would be a wider application of that hash keys can 
already contain any characters, or that named parameter arguments can 
be string-quoted, though the latter are akin to identifiers in the 
method declarations.


Unless its already done, I see that support for this is only 
something that the tokenizer, and perhaps wider parser, of Perl 6 
code has to be concerned with, and all other parts of the Perl 6 
runtime don't have to care.  Because, really, one main reason it 
isn't common place to, say have space characters in variable names, 
is because that could make the parser's job more difficult when 
determining the boundaries of a symbol name in code.


I propose that this can be accomplished with a simple and optional 
de-sugaring of the language that simply provides clues to the 
tokenizer in the form of special delimiters.


For example, if Perl 6 doesn't currently have back-tick (`) 
delimiters reserved (I forget) like Perl 5 does for invoking the Unix 
shell, we could use that; literal occurances of the delimiter 
characters in the identifier would be backslash-escaped as usual like 
with the single-quote (') delimited strings.   Or if you consider 
this being used rarely, we could huffman code to have a longer 
delimiter like "qi()" or "qs()" or something.


If the delimited identifier would be valid as a non-delimited 
identifier (since it only contains alphanums for example), which Perl 
6 code is composed of by default, then delimited and non-delimited 
versions of the same can be intermixed as equivalent; otherwise (eg, 
if they contain whitespace), they appear only in delimited form.


Using the back-ticks as an example, we could say:

  my $baz = 7; # parsed symbol is "baz"
  say $baz;# parsed symbol is "baz"

  my $`foo` = 3; # parsed symbol is "foo"
  say $`foo`;# parsed symbol is "foo"

  my $`the bar` = 5; # parsed symbol is "the bar"
  say $`the bar`;# parsed symbol is "the bar"

Similarly, with subroutine or method names:

  method `do it` (:$`with this`) { ... }

  $myobj.`do it`( 'with this' => 17 );
  $myobj.`do it`( :`with this`<44> );

Note that named arguments can already have string quoted key names, I 
think, this is sort of an extension of that.


Of course, the exact syntax can be different, but I want to not lose 
functionality that I have in other languages and environments when in 
Perl 6.


Unless we have this feature, I would have to resort to either storing 
all symbols in hashes, or hex-escaping them all to ensure useable 
characters without name collisions, and that makes the resulting code 
obfuscated and hard to understand; I don't want to obfuscate.


Thank you. -- Darren Duncan

Re: A proposition for streamlining Perl 6 development

[chromatic]

On Tuesday 07 February 2006 14:17, Yuval Kogman wrote:

> If we have more steps and clearer milestones for whatever is between
> parrot and the syntax/feature level design implementation will be
> easier.

Parrot has had such milestones for well over a year.

> De-facto we have people running PIL on javascript.
> It works more than parrot does.

No, it works *differently* from Parrot, just as an LR parser works differently 
from an LR parser.

Don't make the mistake of thinking "Wow, it took Parrot X months to get a 
working PGE, while the Pugs version only took Y weeks", especially because 
the Pugs version had the benefit of looking at *already designed, debugged, 
and tested* Parrot code.

> The design of Perl 6 itself should be agnostic to where people are 
> developing backends IRL. 

That's a nice goal in the sense of diversity, but I remain unconvinced of its 
utility in speeding up the implementation.  Every abstraction comes at a 
price.  The recent velocity of Pugs toward the goal of running on N multiple 
backends rather than one backend seems to argue that education is still 
cheaper than ignorance.

-- c

PS - Yes, that *is* a Greek-English pun.  Language interoperability is a good 
thing.

Re: A proposition for streamlining Perl 6 development

[Allison Randal]

On Feb 7, 2006, at 13:28, Yuval Kogman wrote:


Apologies if this is insulting to anyone, but personally I think
that Perl 6 (pugs, parrot, everything) is losing too much momentum
lately. I think we need to seriously rethink some of the
implementation plan.


I understand your frustration. I even sympathize, as I had to work  
through this same frustration a few years ago. But, micromanagement  
is not the answer to lost momentum. It actually makes things worse,  
as people throw their effort into defining the problem more and more  
clearly, instead of throwing their effort into producing shippable code.


If it makes you feel any better, pretty much all projects suffer a  
loss of momentum after the first year.


Parrot, on the other hand, has noticeably gained momentum the past 6  
months or so. AFAICT, this is largely due to the fact that we're  
close enough to finished that we can see the light at the end of the  
tunnel, and because Pugs reminded us to hold on to our sense of fun.


Blessings,
Allison

Re: A proposition for streamlining Perl 6 development

[Yuval Kogman]

On Tue, Feb 07, 2006 at 14:02:54 -0800, chromatic wrote:
> On Tuesday 07 February 2006 13:28, Yuval Kogman wrote:
> 
> > Right now the biggest problem in Perl 6 land is project management.
> 
> I disagree, but even if it were true, I don't think the solution is to add 
> more project management and design to partition the process into even more 
> subprojects of nebulous definition and dubious benefit.

Separation to subprojects was not what I meant.

I think the best way to describe it is to take concepts which I
think are correct for writing clean code:

* separation of concerns
* layering
* prefer generic components to specific ones

and to try and apply them to Perl 6's design, which is a bit too big
for any implementation effort to complete as one whole unit.

If we have more steps and clearer milestones for whatever is between
parrot and the syntax/feature level design implementation will be
easier. One way to start creating these milestones is to try to
refactor the design of the language.

> If you *want* Perl 6/Scheme running on Spidermonkey, that's cool.  I just 
> don't see an army of volunteers magically appearing to make it work, not in 
> the least because it's Yet Another Rewrite From Scratch.

That was entirely not my point =(

De-facto we have people running PIL on javascript. It works more
than parrot does. The design of Perl 6 itself should be agnostic to
where people are developing backends IRL.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me wields bonsai kittens: neeyah



pgpMYnuPqj9r2.pgp
Description: PGP signature

Re: A proposition for streamlining Perl 6 development

[chromatic]

On Tuesday 07 February 2006 13:28, Yuval Kogman wrote:

> Right now the biggest problem in Perl 6 land is project management.

I disagree, but even if it were true, I don't think the solution is to add 
more project management and design to partition the process into even more 
subprojects of nebulous definition and dubious benefit.

If you *want* Perl 6/Scheme running on Spidermonkey, that's cool.  I just 
don't see an army of volunteers magically appearing to make it work, not in 
the least because it's Yet Another Rewrite From Scratch.

-- c

Re: A proposition for streamlining Perl 6 development

[Yuval Kogman]

I should note, as integral said, that this direction is generally
being taken by pugs, now that PIR targetting is being worked out
(finally) - i just think it needs to be more explicit and in tune
with the @Larry.

Also, the way pugs is refactoring implies nothing on refactoring and
layering Perl 6's design, which I think is also important.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me does not drink tibetian laxative tea: neeyah!



pgpQnTRA3i2ZH.pgp
Description: PGP signature

A proposition for streamlining Perl 6 development

[Yuval Kogman]

Apologies if this is insulting to anyone, but personally I think
that Perl 6 (pugs, parrot, everything) is losing too much momentum
lately. I think we need to seriously rethink some of the
implementation plan.

The required points of emphasis which I think are slipping out of
our fingers are: code reuse, KISS (on the implementation level).

On the positive side I would like to say that despite my criciticism
I think the Perl 6 community has accomplished a great deal in the
last 5 years, and an especially great deal in the last year (thanks
to pugs serving as a catalyst). Good work everyone!

In a nutshell:

Split the big task that is "Implementing Perl 6" into smaller
chunks detailed herein.

Why is this a problem::

Perl 6 is a very very very rich language. It's got many overlapping
features (a bajillion loops, operators, yadda), many special cases
(Roles, Classes, Traits - they are specializations of a similar
thing), a HUGE library (access to most of the standard C library,
extended math routines, routines for the builtin types, routines for
higher level IO than the standard C library, etc etc etc).

How can it be fixed:

Split Perl 6 into layers stack, instead of mashing it all up.

Perl 6 Core - a simple, concise core language in the spirit of
Scala, Haskell, and all the "cool" languages today. Let's face
it - they have been the most innovative languages of the last 20
years or so in terms of quality, robustness, performance,
extensibility, conciseness. If we copy this we get a solid
foundation. This backend is optionally type checked, contains a
very bare bones object oriented system (prototype + multimethod
seems to me like the most generic approach), etc.

Perl 6 Extended - Using good domain specific language support
(extensible grammer, string macros and core language AST macros)
we implement all the syntax that makes Perl 6 an accessible
language on top of the Perl 6 core. This contains the grammar
for Perl 6 as defined by the synopses.

Perl 6 Prelude - the builtin routines for handling internal data
types, etc. These must be completely portable, and are part of
the internal spec.

Perl 6 Standard Library - contains chunks of stdc, POSIX/Win32
API, generalizations of IO, etc etc. This is mostly portable,
but e.g. fork() will be missing on platform X, that will be
missing on platform Y, etc.

Perl 6 VM support - the prelude compilation ideas I tossed
around several months ago relate to this - *ANY* high level
function can get it's own opcode or low level replacement
function if it's provided. This approach is just a simplified
generalization of the opcode/internal routine pattern, in a way
that can be exploited for performance, rapid development of
backends, testing, having a reference implementation of the
prelude and library, etc. (I will reply to this post with
refernces from the past).

Perl 6 Parrot support - implementing Perl 6 Core, then Perl 6
Extended, then perl 6 Prelude (mostly for performance reasons)
in a way that canonical with the VM support.

-- on the compiler front we can also componentize --

Parser - can parse Perl core, and have it's grammar updated from
callbacks.

Compiler - compiles Perl core to PIL

Interpreter - interprets PIL - slow, but complete

Linker - loads PIL interface files / modules and grammar
extension modules, assists the compiler in disamgiuating, allows
refactoring the parser extensions, and provides necessary info
for the type checker.

Typechecker

These should be implemented in Perl 6 eventually, but not at first.
Pugs is a good start, but requires lots of separation and decoupling
for this to be realized.

Perl 6 Core macros are just functions that accept ASTs as input, and
are invoked at compile time. They are interpreter by the PIL
interpreter if all else fails.

Using these tools Perl 6 Extended can be bootstrapped. At the next
phase we need:

Generic VM Emitter - a "Base class" for implementing VM emitters
that assist in matching functions to opcodes or VM specific
routines.

Parrot core - porting the PIL interpreter, porting bootstrap
code to allow the linker to link compiled modules, bridging
between PIL and PIR up to a point where PIL macros can be
written in PIR, and the compiler can use the PIR backend to run
compile-time PIL.

Note that whenever I say "Parrot" in my opinion you can also shove
"javascript", "llvm", "neko", ".net", "jvm" and whatever else in
there - I think they are equally important (if not more - after all
they are live, production ready targets).

This plan with pugs in mind:

If Audrey is willing, I think a correct new dire

Re: overloading the variable declaration process

[Matt Fowles]

Larry~

On 2/7/06, Larry Wall <[EMAIL PROTECTED]> wrote:
>
> Indeed, and the modeling point of view is that $pipe is *also* just
> a representation of the Pipe.  Neither Pipe nor $pipe is the thing
> itself.  Most computer programs are about Something Else, so computer
> languages should be optimized for talking about other things rather
> than talking about themselves.  The answer to
>
> Pipe.can("Smoke")
> $pipe.can("Smoke")
>
> should be the same, not different.  On the other hand,
>
> ^Pipe.can("Smoke")
>
> is a different matter, insofar as you're asking a question about a Class
> object rather than a Pipe object.  And now you get your Platonism back.
> You just have to be explicit about it.

I see the value of ^Pipe and $pipe as seperate objects which can be
manipulated programmatically.  What I don't really understand is what
exactly Pipe is and where it would be useful.

They way you have described Pipe feels a little muddy to me and I am
unsure about its purpose and semantics.  Is it just an object I ask
`.can()` or does it have some deeper usefulness?

Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary

Re: overloading the variable declaration process

[Larry Wall]

On Mon, Feb 06, 2006 at 10:41:02PM -0500, Matt Fowles wrote:
: Larry~
: 
: On 2/6/06, Larry Wall <[EMAIL PROTECTED]> wrote:
: > This is mostly motivated by linguistics rather than computer science,
: > insofar as types/classes/roles in natural language are normally
: > represented by generic objects rather than "meta" objects.  When I
: > ask in English:
: >
: > Can a dog bark?
: >
: > that's equivalent to asking in Perl 6:
: >
: > Dog.can('bark')
: 
: Or you might think of it more as a question like "Can the ideal of a
: dog bark?"  the answer to which is of course "No, it doesn't exist.".

As soon as you say "the ideal" you've chosen Platonism over
Aristotelianism.  :-)

: Perhaps, I am just too firmly rooted in old paradigms but I think it
: is very important not to conflate the representation of a thing with
: the thing.
: 
: http://en.wikipedia.org/wiki/Image:MagrittePipe.jpg

Indeed, and the modeling point of view is that $pipe is *also* just
a representation of the Pipe.  Neither Pipe nor $pipe is the thing
itself.  Most computer programs are about Something Else, so computer
languages should be optimized for talking about other things rather
than talking about themselves.  The answer to

Pipe.can("Smoke")
$pipe.can("Smoke")

should be the same, not different.  On the other hand,

^Pipe.can("Smoke")

is a different matter, insofar as you're asking a question about a Class
object rather than a Pipe object.  And now you get your Platonism back.
You just have to be explicit about it.

Larry

Re: overloading the variable declaration process

[Ashley Winters]

On 2/6/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> So the basic answer to you question is, I think, yes.  If Dog chooses
> to always return true for .defined, then (in Haskell terms) it's more
> like a Just type than a Maybe type.  Perl 6's objects like to be Maybe
> types by default, but you can override it.  (I'm using the Haskell
> terms loosely here, of course.)  But the very concept of definedness
> is getting mushy in Perl 6.  What we need is more concepts of the
> form "Is this *sufficiently* defined for what I want to do with it?"
> That's why I proposed "defined according to a particular role" as
> one way to ask that sort of question.

So, if ^Dog describes a Dog which defines a $dog, do we need an
undescribed() function?

Just kidding... kinda.

Ashley Winters