Re: overloading the variable declaration process
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
Re: overloading the variable declaration process
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
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
A proposition for streamlining Perl 6 development
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 direction for pugs is
Re: A proposition for streamlining Perl 6 development
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
Re: A proposition for streamlining Perl 6 development
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
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
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.
tokenizer hints, supporting delimited identifiers or symbols
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: tokenizer hints, supporting delimited identifiers or symbols
say $::You can already do that!; Larry
Re: A proposition for streamlining Perl 6 development
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
At 3:28 PM -0800 2/7/06, Larry Wall wrote: say $::You can already do that!; 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
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 elsewhere so
Re: tokenizer hints, supporting delimited identifiers or symbols
On Tue, Feb 07, 2006 at 03:28:05PM -0800, Larry Wall wrote:
: say $::You can already do that!;
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::x y # same thing
MY::$x y # same thing
$GLOBAL::{'x y'}
$GLOBAL::x y # 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::x y
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 $::foo and ::$foo
(except you can't interpolate the last one in a string directly).
Larry
Re: A proposition for streamlining Perl 6 development
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: overloading the variable declaration process
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_ofebony,
:colorblack,
:lengthshort
);
has $bowl = Pipe::Bowl.new(
:composed_ofmahogany,
:colorbrown,
:sizemedium
);
}
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[$typeAnniversay];
}
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 RD
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 has $filter =
bool::false; just provide a default?
You would then model the different pipes you sell;
class MagrittePipe {
has $stem = Pipe::Stem.new(
:composed_ofebony,
:colorblack,
:lengthshort
);
has $bowl = Pipe::Bowl.new(
Re: A proposition for streamlining Perl 6 development
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: tokenizer hints, supporting delimited identifiers or symbols
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 $::You can already do that!;
: 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 .x y.
Larry
Re: A proposition for streamlining Perl 6 development
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: overloading the variable declaration process
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 has $filter =
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_ofebony,
:colorblack,
:lengthshort
);
has $bowl = Pipe::Bowl.new(
:composed_ofmahogany,
:colorbrown,
:sizemedium
);
}
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 RD
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:) {
say I am a class method, and proud of it;
}
}
And whalla,
The definition of 'say'
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 foo
is exactly equivalent to
print foo, \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 foo }
I've searched the archives of this list, but failed to turn
up anything relevant.
Cheers,
Robin
Re: A proposition for streamlining Perl 6 development
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
Re: A proposition for streamlining Perl 6 development
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
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 RD 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 maybe, as more and more people do it, they will find
Perl 6 Summary for 2006-01-24 though 2006-02-07
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. http://xrl.us/jws4 Pugs Makefile.PL Update Beau E. Cox posted a patch to improve Makefile.PL. Audrey added it and handed him a commit bit. http://xrl.us/jws5 Pugs 3.2.11 Pugs, now officially 1 year old, just hit its 6.2.11 release. http://xrl.us/jws6 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. http://xrl.us/jws7 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. http://xrl.us/jws8 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$. http://xrl.us/jws9 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. http://xrl.us/jwta PGE Binding Audrey noticed a problem convincing PGE to alias a scalar. Patrick explained that it was not yet implemented. http://xrl.us/jwtb 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. http://xrl.us/jwtc Interpreters and Stashes? Leo posted a few questions about parts of Parrot's guts that he wasn't sure about. Chip posted his thoughts. http://xrl.us/jwtd File, OS, and Path Alberto Simões posted his proposal for File/OS functions. Chip provided his opinions as well. http://xrl.us/jwte 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. http://xrl.us/jwtf 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. http://xrl.us/jwtg 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. http://xrl.us/jwth Dirty I Registers Jerry Gay noticed that IREGs weren't being zeroed properly. http://xrl.us/jwti Parrot::Configure::Data::Bug Norman Nunley found and fixed a bug in Parrot::Configure::Data. Leo applied the patch. http://xrl.us/jwtj 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. http://xrl.us/jwtk Invalid Cleaning Order Bernhard Schmalhofer noticed that make clean was cleaning itself into a corner. He filed a bug for it. http://xrl.us/jwtm FreeBSD JIT Bug Joshua Isom found a problem with the FreeBSD JIT. Leo pointed him to some docs to help him debug his problem. http://xrl.us/jwtn Makefile Cleanup Joshua Isom posted a patch cleaning up some makefile stuff. Joshua Hoblitt thought that further review was necessary. Warnock applies. http://xrl.us/jwto 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. http://xrl.us/jwtp Truncating Generated PIR Code Allison Randal was having problems with generated PIR code getting truncated. Leo managed to track down and solve the problem. http://xrl.us/jwtq 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. http://xrl.us/jwtr Exception in a Constructor Oddness Jonathan Worthington provided a test case display an unexpected interaction between constructors and exceptions. Warnock applies. http://xrl.us/jwts Continuation Return Values Bob Rogers provided a patch allowing Continuations to return values. Leo applied the patch. http://xrl.us/jwtt Dynamic PMC Link Dependency Leo noticed that compiling a static
Re: overloading the variable declaration process
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
Re: A proposition for streamlining Perl 6 development
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: tokenizer hints, supporting delimited identifiers or symbols
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::x y # 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::x y
: $My::{'x','y'}
Er, yeah. My bad.
Larry
Re: A proposition for streamlining Perl 6 development
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
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 $::You can already do that!;
:
: 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 $::bar = 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
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: A proposition for streamlining Perl 6 development
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
Smart match table
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
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
