Re: Synopses updated on dev.perl.org

[Dan Sugalski]

At 9:26 AM -0800 11/22/04, Larry Wall wrote:
I finally managed to get the newest synopses and apocalypses up on
dev.perl.org, so please consider my www.wall.org directories deprecated.
[snip[
Anyway, the dev.perl.org pages are presumably linkable, unlike my
www.wall.org pages.  But it might be better to wait till everyone is
back from turkeytime before you send it off to the slashdot editors.  :-)
And if everyone'd think *real* hard before actually submitting to 
splashblot (and, hopefully, deciding not to) I'd appreciate it. I 
feel obligated to actually *read* the comments on parrot and perl 6 
stories on slashdot, at 0, so if I don't actually have to do so, 
well... so much the better usually. :)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Perl 6 Summary for 2004-11-01 through 2004-11-08

[Dan Sugalski]

At 10:39 PM -0500 11/8/04, Matt Fowles wrote:
   calling convenctions, traceback, and register allocation
Leo suggested a new way to invoke functions which would clean up
calling, tracebacks, and register allocation. While such a change would
have great aesthetic value, Dan declared it premature as parrot is not
yet fully specified. Doubtless this will rearrise later, as aesthetics
is a powerful motivator.
It's important to note that aesthetically I don't have a problem with 
the current system...
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: This week's summary

[Dan Sugalski]

At 1:26 PM +0100 8/9/04, The Perl 6 Summarizer wrote:
  Spilling problems
The thing about writing naive compilers for naive languages is you end
up with rather large Parrot subroutines. Dan's work project is
generating ~6000 line subs.
That was only for a program triggering degenerate behaviour in the 
register allocator. The biggest sub I can find off-hand is 69496 
lines, from an original source language that stuffs about 400K of 
source text into a single routine...
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: This week's summary

[Dan Sugalski]

On Thu, 8 Jul 2004, Piers Cawley wrote:

 Jonadab the Unsightly One [EMAIL PROTECTED] writes:

  The Perl 6 Summarizer [EMAIL PROTECTED] writes:
 
Different OO models
  Jonadab the Unsightly One had wondered about having objects
  inheriting behaviour from objects rather than classes in Perl 6.
 
  Urgle.  I've completely failed to explain myself so as to be
  understood.  That wasn't at *all* what I had in mind.

 It could well be that I didn't read things carefully enough.

Maybe, but that's what I got out of it as well.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Time to change the (perl 6) guard!

[Dan Sugalski]

Or at least lay on more. Here's the scoop--we need a Perl 6 pumpking,
someone to take on the responsibility of making the Perl 6 compiler
happen. When we started this whole process these many years ago, we
though having one person handle the software end of things was
sufficient, but making perl 6 a reality is a much larger task than we'd
originally figured, as both Perl 6 the language and Parrot the
interpreter have ended up bigger than we'd thought they'd be. Bigger,
in fact, than one person can reasonably manage, especially with a
volunteer project.
Hence, the call. Got people skills? Can you organize? Competently
*design* code? Got free time?  Work with people who are, well, Larry?
Cool, this is for you. You don't have to be a star programmer, nor a
parser or compiler whiz, though that certainly won't hurt.
Enthusiasm's what you need, as there are people willing to help you
out with the rest.
There are plenty of things you don't have to worry about. You don't
have to worry about the language design--that's Larry's job. Nor do
you have to worry about the interpreter engine--that's Dan's
job. What you'll have to do is get the Perl 6 compiler module, and
its standard library, designed and implemented.
It's a big job, but someone has to do it, and that someone could be
you. (As a bonus, you get your own Secret Perl Cabal membership card
and Decoder ring!) If you're interested, make your pitch to our
esteemed, and mostly sane, Perl 6 manager-type person Allison Randal,
at [EMAIL PROTECTED]
Good luck!
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Time to change the (perl 6) guard!

[Dan Sugalski]

At 6:21 AM -0700 7/6/04, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
 we need a Perl 6 pumpking,
Luke Palmer.
No fair volunteering other people, though I'd be happy to forward 
*your* volunteering on to Allison... :-P
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Next Apocalypse

[Dan Sugalski]

On Tue, 29 Jun 2004, Jonadab the Unsightly One wrote:

 Austin Hastings [EMAIL PROTECTED] writes:

  Of course, how hard can it be to implement the .parent property?

 .parent and also .children, plus .moveto and .remove (which doesn't
 actually destroy the object but sets its parent to undef, basically,
 cleaning up the .children property of its parent), and a couple of
 extra routines for testing ancestor relationships and stuff, but...

Sure, no big deal. Also, don't forget the trival matter of moving from a
class-based object system to a prototype based one. (Since right now
objects don't *have* parent objects (just parent classes), or child
anythings) While making things still look like they're a class-based
system for all the code and programmers who're used to that.

No problems there, I'm sure. Patches, of course, are welcome.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: more than one modifier

[Dan Sugalski]

On -1 xxx -1, it was written:


  I have a wish for Perl6. I think it would be nice to have the possibility
  for more than one modifier after a simple statement.

Larry's ruled that it's one statement modifier per statement, period. For
anything else you'd need to modify the grammar. (Which won't be difficult)

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: The .bytes/.codepoints/.graphemes methods

[Dan Sugalski]

On Mon, 28 Jun 2004, Larry Wall wrote:

 On Mon, Jun 28, 2004 at 11:26:32AM -0400, Jonadab the Unsightly One wrote:
 : You could coin the abbreviation ligs, for Language Independent
 : Graphemes.  Then some ingenious rascal can create a pragma or whatever
 : that allows $str.b, $str.c, $str.g, and $str.l for fans of terseness.

 Except they'd have to be ldgs.  Graphemes are ligs in current parlance.

And 'ligs' implies ligatures. And since that'd require font, style, and
possibly layout information, I think we'd rather not go there right now...

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: The .bytes/.codepoints/.graphemes methods

[Dan Sugalski]

On Mon, 28 Jun 2004, Juerd wrote:

 Dave Whipp skribis 2004-06-28  9:55 (-0700):
   substr($string, 2 bytes, 4 bytes) = $substitute;
  substr($string, 2, 4 :bytes)

 substr($string, 2 but graphemes, 4 but bytes);

 I think but even makes sense, if substr defaults to something.

I think mixing strings, bytes, graphemes, and code points together is a
phenomenally bad idea, likely to lead to many tears, much gnashing of
teeth, and quite a few rampages with sharp objects, not to mention a lot
of code guaranteed to fail at the edge cases.

If, as a programmer, you *really* want to run with scissors then convert
your string to a binary byte buffer and go from there. At least then when
you poke out an eye you won't be nearly so surprised.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: The .bytes/.codepoints/.graphemes methods

[Dan Sugalski]

On Mon, 28 Jun 2004, Austin Hastings wrote:

 --- Dan Sugalski [EMAIL PROTECTED] wrote:
  On Mon, 28 Jun 2004, Juerd wrote:
 
   Dave Whipp skribis 2004-06-28  9:55 (-0700):
 substr($string, 2 bytes, 4 bytes) = $substitute;
substr($string, 2, 4 :bytes)
  
   substr($string, 2 but graphemes, 4 but bytes);
  
   I think but even makes sense, if substr defaults to something.
 
  I think mixing strings, bytes, graphemes, and code points together
  is a phenomenally bad idea, likely to lead to many tears, much
  gnashing of teeth, and quite a few rampages with sharp objects,
  not to mention a lot of code guaranteed to fail at the edge cases.

 Hmm. Suppose that I have a system that is friendly to 80 byte records.
 I want to output meaningful strings, so I want to partition a buffer
 into 80-ish byte substrings, but preserve any graphemes (i.e., store
 the data in a legible format).

 How would I do that?

You don't. Or if you do, you do it with a lot of pain, sweat, and annoying
hard work. 80 bytes gets you somewhere between three (And this may be a
*high* estimate--there may be circumstances where 80 bytes is
insufficient for *one* grapheme) and 80 graphemes.

This isn't something that can be made generically easy.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: This fortnight's summary

[Dan Sugalski]

On Wed, 23 Jun 2004, The Perl 6 Summarizer wrote:

   Bignums!
 Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up
 to the plate. Leo suggested that, rather than starting from
 types/bignum.c, it might be better to use an existing, maintained, maths
 (Look, I'll spell 'summarise' with a 'z' -- the OED does -- but it will
 be a cold, cold day in hell when I start abbreviating 'mathematics' as
 'math'. Ahem.) package. Dan worried about license compatibility; the
 proposed GMP package is licensed under the LGPL which may (or may not)
 be compatible with Parrots Artistic/GPL dual licence. After a closer
 reading he reckoned that GMP's license is definitely incompatible with
 Parrot.

 http://groups.google.com/[EMAIL PROTECTED]

The license issues there require that the full source of GMP ship with any
binary copy. (the license has no provide a place to fetch it
provision--the source is required) Which would make the Gameboy version
of Parrot somewhat cumbersome. :)

   Resizeable*Array classes
 Fresh from his Fixed Array triumph, Matt Fowles posted a patch
 implementing nave Resizeable Arrays. Leo thought it a little too nave,
 and worried about duplication of existing functionality. Dan wasn't
 worried about the navet, or the duplication of functionality. He
 pointed out that it was more important to get *something* which could be
 improved and that the duplication was okay given that the idea was to
 get a standard framework in place and then eliminate the duplication. (I
 admit that I'm a little surprised to hear Dan, who's normally a strong
 advocate of up front design, preaching the refactorers creed...)

Ah, but the design is already fixed. And I'm a big advocate of I don't
care if it's implemented by the appropriate application of garden gnomes
so long as it works school of thought. The code is close to irrelevant,
it's the architecture and API of a black box and the system that
box exists in that's important.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Apocalypse 6: IDs of subroutine wrappers should be objects

[Dan Sugalski]

On Tue, 8 Jun 2004, David Storrs wrote:

 On Tue, Jun 08, 2004 at 01:08:13PM -, Ingo Blechschmidt wrote:
  Hello,
 
  quoting Apocalypse 6:
   You may ask a subroutine to wrap itself up in another subroutine in
   place, so that calls to the original are intercepted and interpreted by
   the wrapper, even if access is only through the reference:
  
   $id = $subref.wrap({
   # preprocessing here
   call;
   # postprocessing here
   }
  [...]
   The $id is useful for removing a particular wrapper:
  
  $subref.unwrap($id);

 Hmmm.  What happens when I do this?:

$id1 = $subref.wrap({ stuff });
$id2 = $subref.wrap({ more stuff });
$id3 = $subref.wrap({ other stuff });
$id4 = $subref.wrap({ different stuff });

$subref.unwrap($id3);

 First off, is this even valid?

I'm pretty sure it is, yes.

 Second, what does it do under the hood?

First, it sends e-mail to our Quantum Ninjas who may or may not do
Horrible Things to you... (We're never sure)

 Does it need to tear off
 wrappers 1 and 2 before tearing off #3?  Does it need to recompile
 wrappers 1 and 2?

There's no compilation for wrappers when they're installed, so there won't
be any need to recompile on removal. Wrappers will all be done with
chained PMCs, so we'll just remove the removed wrapper from the chain.

 What kind of speed hit am I looking at?

Should take no more than a week, on average. Two, tops.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: is rw trait's effect on signature

[Dan Sugalski]

At 10:44 AM -0700 5/6/04, chromatic wrote:
On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
 The simple case is:
sub foo(X $i is rw) {...}
class X {...}
class Y {...}
my Y $var = 'something';
foo($var);
 In this case, something kind of interesting has to happen.
 Either the signature checking has to verify that Y isa X (and thus can
 be used polymorphically as X, not just converted to X) ...
I'd argue 'Y does X', actually, though Dan disagrees and says Well,
whatever!
Nope. Dan says Is that X in the signature an assertion of interface 
or of parentage? and has the Perl 6 compiler emit the appropriate 
code. (Parentage is the safer option generally, since only in perl 6 
is the class == interface assertion going to be true, and you might 
want to be able to yank in Python/Ruby/Perl5/Objective-C/Java/C#/C++ 
objects and classes. Or... you might not, which is fine too)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: is rw trait's effect on signature

[Dan Sugalski]

At 11:03 AM -0700 5/6/04, Larry Wall wrote:
On Thu, May 06, 2004 at 01:52:45PM -0400, Dan Sugalski wrote:
: At 10:44 AM -0700 5/6/04, chromatic wrote:
: On Thu, 2004-05-06 at 10:39, Aaron Sherman wrote:
: 
:  The simple case is:
: 
:   sub foo(X $i is rw) {...}
:   class X {...}
:   class Y {...}
:   my Y $var = 'something';
:   foo($var);
: 
:  In this case, something kind of interesting has to happen.
: 
:  Either the signature checking has to verify that Y isa X (and thus can
:  be used polymorphically as X, not just converted to X) ...
: 
: I'd argue 'Y does X', actually, though Dan disagrees and says Well,
: whatever!
:
: Nope. Dan says Is that X in the signature an assertion of interface
: or of parentage? and has the Perl 6 compiler emit the appropriate
: code. (Parentage is the safer option generally, since only in perl 6
: is the class == interface assertion going to be true, and you might
: want to be able to yank in Python/Ruby/Perl5/Objective-C/Java/C#/C++
: objects and classes. Or... you might not, which is fine too)
I don't see a problem with using does sematics in Perl 6 because
roles and classes live in the same namespace, and does naturally
devolves to isa semantics if you hand it a class.
Well... sort of, but only because you've defined that for perl 6 
classes automatically do themselves--you've conflated inheritance and 
interface. Which is fine, except that it falls down in the face of 
objects from classes that don't do that.

We can't devolve to isa checking under the hood, because there are 
cases where a class can assert that it has a role without pulling in 
the role externally. (Storable, for example, will be a likely thing 
here as classes assert they do Storable without pulling in an 
external Storable role, since a generic Storable's generically 
useless) So there will be classes that have a role in them without 
having a class of the same name in their inheritance hierarchy 
anywhere.

Does, though, can only check the assertions of whether a class does 
the role in question--it can't check inheritance, because while Perl 
6 makes roles and classes more or less the same (kinda sorta) that's 
not true of other languages. If I have an Objective-C or Java object 
of class Foo, and Foo implements the Bar interface, then that object 
does(Bar) while not being isa(Bar), and isa(Foo) without does(Foo). 
Ruby's mixins behave similarly.

In an all-Perl 6 environment it should work out OK if Perl 6's 
signature checking conflates isa and does (unless you're going to add 
a doesn't to class definitions :) but it's going to make things 
potentially interesting in a mixed-language environment which is 
reasonably likely.

Not, mind you, that it necessarily matters, but it's good to make 
sure things are clear (whether it's an isa or a does check) and it 
may be useful to have specific syntax if people want to be explicit 
whether they're checking isa or does. (Or can, I suppose, if you want 
to go that far)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: is rw trait's effect on signature

[Dan Sugalski]

At 11:42 AM -0700 5/6/04, chromatic wrote:
On Thu, 2004-05-06 at 11:24, Dan Sugalski wrote:
 Well... sort of, but only because you've defined that for perl 6
 classes automatically do themselves--you've conflated inheritance and
 interface. Which is fine, except that it falls down in the face of
 objects from classes that don't do that.
Given:
- class A,  a superclass
- class AB, a subclass of A
- class Eh, a class that does A but does not inherit from it
- subroutine signature foo(A some_object)
If the signature checker checks isa, you can't pass in Eh, even though
its writer has guaranteed that its semantics match those of A.
If the signature checker checks does, you can pass in A, AB, or Eh,
assuming that subclassing marks does on the subclass *or* that you fall
back to checking isa if does fails.
Either will probably work, but you and I both agree there's a problem in
that does and isa overlap somewhat.  We disagree on the implications of
that overlap, though.
It's a matter of perspective as much as anything else. And, I'll add 
again, I don't care which it is. Both ways have implications and 
limits, and either way is fine.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: Required Named Parameters Strike Back!

[Dan Sugalski]

At 1:55 PM -0700 5/5/04, Larry Wall wrote:
On Wed, May 05, 2004 at 04:25:45PM -0400, Austin Hastings wrote:
: In this case, the reliance on saying:
:
:   if (+$x  9) ...
:
: to disambiguate logical/arithmetic/string/whatever context in expressions is
: going to sit at cross purposes to the +-as-required-arg usage. It'll be yet
: another source of learning curve gradient to no real purpose.
:
: method x ($me: $req, ?$opt, +$namedopt, *%named, [EMAIL PROTECTED]) {...}
: vs:
: method x($me: $req, ?$opt, ~$namedopt, *%named, [EMAIL PROTECTED]) {...}
Using ~ is not an improvement in that respect.  Named arguments are
not in string context.
Looking at this, all I can think is I hope there's a long-form of 
all this punctuation notation for those of us old and feeble folks.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: a doubt about .meta, .dispatcher and final methods

[Dan Sugalski]

At 8:24 AM -0700 4/23/04, Larry Wall wrote:
On Fri, Apr 23, 2004 at 10:37:00AM -0400, Aaron Sherman wrote:
: It's a fine point... in the past, P5 and P6 have up-cased such
: constructs in order to warn of their semi-keywordishness (e.g. DESTROY
: or BUILD). I'm wondering why Larry chose to leave dispatcher and meta
: lower in this case.
Hmm, yes.  Well, I chose those for a very strong reason--I hadn't
thought about the issue yet.   :-)
I often throw things into Apocalypses that are placeholders when I
know there wants to be something there, but I don't necessarily know
what the right name is yet.
Generally I think of the uppercase names as ones that get called
automatically most of the time.  But there's also a history of
uppercasing reserved names in general.  (Though most of these are
turning into ordinary variable names like $*OUT and @*ARGS).  So we
could uppercase these.
On the other hand, $obj.META.does is ugly.  But maybe it should be ugly.

On the third hand, maybe we should go for $obj._meta_ or some such.

On the fourth hand, maybe it's okay to stick with .meta.

On the fifth hand, since it's aiming at a MetaClass, maybe it should
be C.Meta.
On the sixth hand, by that argument, since .dispatcher is aiming at
a Class, it should be an uppercase C.   :-)
On the seventh hand, why not make it a property that can be put on 
any method, which punts the problem out a whole 'nother level? :)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A question about binary does

[Dan Sugalski]

At 2:21 PM -0500 4/22/04, Abhijit A. Mahabal wrote:
This is actually a couple of questions:
1: can you extend roles by saying: role Set is extended {}
Parrot will allow this, so if Larry says OK you're fine. It may be 
rather significantly expensive, however. (Not nearly as bad as, say, 
adding an attribute at runtime to a heavily instantiated class, 
but...)

2: if yes, does this change variables for which you said  $var does Set?
Well, it changes the *classes* for which you said $var does Set. When 
you throw a role on an object we're making an anonymous sub-class, so 
altering the role alters the anonymous subclass rather than the 
object in the subclass.

In other words, is the singleton class like a closure or a first-class
class?
I'm not sure how the above questions relate to this, but singleton 
classes are real first-class classes.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

RE: A12: Conflicting Attributes in Roles

[Dan Sugalski]

At 2:37 PM -0700 4/23/04, Jonathan Lang wrote:
Austin Hastings wrote:
 Jonathan Lang  wrote:
  role A {has Cat $.x;}
  role B {has Dog $.x;}
  class Foo {does Cat; does Dog;}
  my Foo $bar;
  $bar.x;  # Is this a Cat or a Dog?
 A12
 If, however, two roles try to introduce a method of the same name (for
 some definition of name), then the composition of the class fails, and
 the compilation of the program blows sky high--we sincerely hope. It's
 much better to catch this kind of error at compile time if you can. And
 in this case, you can.
 /A12
 Since classes are autogenerating accessors based in data members, it's
 doubly reasonable to assume that the same solution will apply: conflict
 - death.
Note that the problem extends past accessors: a role's methods can access
its attributes directly.  So:
  role A {has Cat $.x; method m1 {return $.x;};}
  role B {has Dog $.x; method m2 {return $.x;};}
  class Foo {does Cat; does Dog;}
  my Foo $bar;
  $bar.m1; # returns $A::x, right?
  $bar.m2; # returns $B::x, right?
If the two $.x's are completely equivelent, you end up with redundant data
storage.
I'd think, assuming roles are allowed to add attributes (and, if so, 
I'd argue what's the difference between a class and a role, then? 
but someone'd hit me), that the attribute would be role-specific. In 
the above case you'd have two separate attributes.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: subtypes that lack methods or roles

[Dan Sugalski]

At 6:12 PM -0700 4/23/04, Larry Wall wrote:
On Fri, Apr 23, 2004 at 03:07:23PM -0700, Jonathan Lang wrote:
: How would I declare a subtype of a class which messes with the dispatching
: mechanism to exclude certain methods and/or roles from it? 

Er, uh...tell you what.   Why don't you provide some sample code to
go with your question, and we'll just tell Dan to make it work.  :-)
No problem.

Throwing an exception counts as working, right? :-P
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: Required Named Parameters Strike Back!

[Dan Sugalski]

At 9:50 AM -0400 4/20/04, John Siracusa wrote:
On 4/19/04 7:16 PM, Larry Wall wrote:
  Well, no, we're still stuck at run-time validation of that.  In the case
 of methods you can't really do anything else anyway, generally speaking.
Why is that?
Because at compile time all you have is a generic thing, a (possibly 
indirectly accessed) method name, and a list of parameters. There's 
no good way to tell which method will ultimately be called, and 
validating against all declared methods of that name won't get you 
anything useful there since the result's likely going to be pretty 
contradictory.

  since we've told the Parrot people they don't have to worry about
 anything but positional parameters for 6.0.0.
Can we do some magic behind the scenes that will make required named
params look positional to parrot?
Maybe. There are issues of indirect named parameters (where you pass 
in a scalar ref to a pair, which if I've read properly should be 
treated as a named parameter) though we could have the compiler shift 
'em all to the end.

The problem there is that positional parameters have to maintain 
their position of the destination sub has no names--we can't go 
reordering things for subs that do the traditional:

   sub foo {
  my ($bar, $baz, $plugh) = @_;
   }
in that case the positional parameters need to stay where they are. 
They also can't move if the destination sub or method doesn't do 
named parameters (because either it doesn't or it's not perl 6) since 
in that case the named parameters need to degrade nicely (and in 
place) to their values.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: Required Named Parameters Strike Back!

[Dan Sugalski]

At 10:51 AM -0400 4/20/04, John Siracusa wrote:
On 4/20/04 10:42 AM, Dan Sugalski wrote:
 At 9:50 AM -0400 4/20/04, John Siracusa wrote:
 On 4/19/04 7:16 PM, Larry Wall wrote:
 Well, no, we're still stuck at run-time validation of that.  In the case
  of methods you can't really do anything else anyway, generally speaking.
 Why is that?
 Because at compile time all you have is a generic thing, a (possibly
 indirectly accessed) method name, and a list of parameters. There's
 no good way to tell which method will ultimately be called, and
 validating against all declared methods of that name won't get you
 anything useful there since the result's likely going to be pretty
 contradictory.
Hm, so how would the is required trait that Damian posted work?  Would it
simply be shorthand for a run-time check that I don't have to write myself?
Yes. It may have the added advantage of continuing the search for a 
sub that matches--that is, we could continue on as if we'd not found 
the sub and then hit MMD. Or not. I could see it going either way.

It really is a shame about the inability to do it at compile-time with
methods, but shorthand for a run-time check in that case would be welcome
too :)
Everybody's OO gets hit this way, unless you get really vicious with 
the signatures of overridden methods. (If they're all the same it's 
easier) Perl's really dynamic nature makes it tough for subs, too.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: Required Named Parameters Strike Back!

[Dan Sugalski]

At 1:14 PM -0400 4/19/04, John Siracusa wrote:
I know we are running out of special characters, but I really, really think
that required named parameters are a natural fit for many common APIs.
Well... maybe, but ponder a likely common case--automatically 
redelegated initialization methods with classes that have parents 
written in languages without named parameters. (Like, say, all the 
rest...)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A12: Required Named Parameters Strike Back!

[Dan Sugalski]

At 1:50 PM -0400 4/19/04, John Siracusa wrote:
On 4/19/04 1:41 PM, Dan Sugalski wrote:
 At 1:14 PM -0400 4/19/04, John Siracusa wrote:
 I know we are running out of special characters, but I really, really think
 that required named parameters are a natural fit for many common APIs.
 Well... maybe, but ponder a likely common case--automatically
 redelegated initialization methods with classes that have parents
 written in languages without named parameters. (Like, say, all the
 rest...)
Then either make the order part of the API (Sorry, we're using a C lib!)
or provide manual delegation with an arg-ordering wrapper.  Calling out to
lesser languages is always bound to be crufty... ;)
Um. Yeah. I think it's safe to say you're going to have positional 
args in core APIs for an awfully long time to come.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Compatibility with perl 5

[Dan Sugalski]

At 4:07 PM +0100 4/13/04, Matthew Walton wrote:
Thomas A. Boyer wrote:

Matthew Walton wrote:
That could be problematic, because if Perl 6 sees something like:

my %myhash;
%myhash{'foo'} = 'bar';
Is it going to think 'ahah, perl 6' or 'perl 5 with errors'?


It's going to think 'ahah', perl 5'. Because it doesn't contain any 
Perl 6 keyword (such as 'module' or 'class'), as Mark said.
But then trying to process that as Perl 5 will result in an error. 
This doesn't seem particularly sane to me. Will we have to say

use 6;

on all Perl 6 programs to avoid this kind of thing?

Forgive me if I'm missing something obvious here.
You're not, and there is no guaranteed universal heuristic. Being 
explicit, via command line switches or executable names, is the 
prudent way to go.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: New functions in the core (Was Re: Dereferencing Syntax)

[Dan Sugalski]

At 6:59 AM + 3/27/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Joe Gottman) writes:
 This function would be very useful in inner loops, so if it is possible to
 implement it more efficiently in the core than as a sub in a module I think
 we should do so.
And, if it's possible to implement it more efficiently in the core than as a
sub in a module that Parrot didn't live up to one of its design principles.
Erm... I suppose. As long as you've written the module code in C...
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Some questions about operators.

[Dan Sugalski]

At 9:19 PM + 3/20/04, Simon Cozens wrote:
[EMAIL PROTECTED] (Austin Hastings) writes:
  I'm not sure that having quaternary logic in Perl 6 is necessarily a good
  idea. Why stop only at four states?
 Total about twelve possible states plus junctions, of which eight or nine
 would be 'useful', and only three would be knowingly used.
Irony is wasted on perl6-language.
And this is a new revelation?
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Compile-time undefined sub detection

[Dan Sugalski]

At 12:30 PM -0800 3/15/04, Larry Wall wrote:
On Sat, Mar 13, 2004 at 08:39:02PM +0100, James Mastros wrote:
: Larry Wall wrote:
: And how would it differ from END?  You can't predict when the last
: time a module is going to get used...
:
: Unless we support an explicit unload action on modules.  This seems
: highly useful for long-running processes.  (I don't think making them
: DODable is useful, since there's no way to tell if a future eval STRING
: (or equiv) might be useful.)
Then the explicit unload can call an explicit routine in the module
for cleanup, I suspect.
That's going to be the only way to reasonably unload a module, and 
even then there'll be some interesting repercussions. Like... what 
happens when you unload a module with instantiated objects? How can 
you tell if there are secondary modules that need unloading? Does 
unloading actually unload, or just remove as many links to the module 
as we can and we then unload it when the last real reference to it 
goes away? Can we *re*load a module that's been unloaded? (The answer 
to that last one's no, for some modules that load in external 
libraries)

It's an interesting problem. Modules leave debris around which can 
make it difficult to properly deal with, and allowing them to be 
unloaded requires a fair amount of thought.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Latin-1-characters

[Dan Sugalski]

At 12:28 AM +0100 3/16/04, Karl Brodowsky wrote:
Anyway, it will be necessary to specify the encoding of unicode in
some way, which could possibly allow even to specify even some 
non-unicode-charsets.
While I'll skip diving deeper into the swamp that is character sets 
and encoding (I'm already up to my neck in it, thanks, and I don't 
have any long straws handy :) I'll point out that the above statement 
is meaningless--there *are* no Unicode non-unicode charsets.

It is possible to use the UTF encodings on non-unicode charsets--you 
could reasonably use UTF-8 to encode, say, Shift-JIS characters. 
(where Shift-JIS is both an encoding and a character set, and it can 
be separated into pieces)

It's not unwise (and, in practice, at least in implementation quite 
sensible) to separate the encoding from the character set, but you 
need to be careful to keep the separation clear, though many of the 
sets and encodings don't go out of their way to help with that.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Latin-1-characters

[Dan Sugalski]

At 11:36 PM + 3/15/04, [EMAIL PROTECTED] wrote:
Another possibility is to use a UTF-8 extended system where you use 
values over 0x10 to encode temporary code block swaps in the 
encoding.  I.e.,
some magic value means the one byte UTF-8 codes now mean the Greek block
instead of the ASCII block.
You could do that, but then I'd be forced to do something well and 
truly horrible to you, and we'd rather not have that. :)

Character set and encoding are metadata, and ought be stored 
out-of-band, at least once the data makes it into your program. 
Twiddling the internal representation of the bytes is a fairly 
sub-optimal way to do that, so I'd as soon not mandate that we have 
to. (I do dislike publically breaking mandates like that. Terribly 
inconvenient)

  At 12:28 AM +0100 3/16/04, Karl Brodowsky wrote:
 Anyway, it will be necessary to specify the encoding of unicode in
 some way, which could possibly allow even to specify even some
 non-unicode-charsets.
 While I'll skip diving deeper into the swamp that is character sets
 and encoding (I'm already up to my neck in it, thanks, and I don't
 have any long straws handy :) I'll point out that the above statement
 is meaningless--there *are* no Unicode non-unicode charsets.
 It is possible to use the UTF encodings on non-unicode charsets--you
 could reasonably use UTF-8 to encode, say, Shift-JIS characters.
 (where Shift-JIS is both an encoding and a character set, and it can
 be separated into pieces)
 It's not unwise (and, in practice, at least in implementation quite
 sensible) to separate the encoding from the character set, but you
 need to be careful to keep the separation clear, though many of the
  sets and encodings don't go out of their way to help with that.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Compile-time undefined sub detection

[Dan Sugalski]

At 8:47 AM +1100 3/6/04, Damian Conway wrote:
Larry wrote:

Anybody got opinions on the naming of these beasts?  Certainly *not*
renaming CHECK is more compatible with Perl 5.
I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with
Perl 5 and with software engineering jargon.
How 'bout we make these properties on the subs instead of custom sub 
names? There are some times when its useful to have a sub callable by 
name as well as at a specified time in the startup sequence. (Which 
is what parrot'll be doing *anyway*--BEGIN blocks will be subs with 
bogus names with the :begin property on them, or something like that)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

1st International Workshop on Interpreted Languages

[Dan Sugalski]

It's open for proposals and such. Quoth the organizer:

  the workshop is now officially announced and the Call for Papers has
  started
http://www.sebastian-bergmann.de/InterpretedLanguages2004/

Look 'em up and put in a paper. Should be fun.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: The Sort Problem: a definitive ruling

[Dan Sugalski]

At 2:49 PM -0700 2/20/04, Luke Palmer wrote:
After this statement:

$x = '345';

C$x is a number.
No, it isn't. It's a string. Or, rather, it's a PerlScalar.

I should hope it would be treated as one during
multimethod dispatch.
I should certainly hope *not*. If so, it's a bug. We ought to go add 
some tests to the test suite once we expose this bit of the engine.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Traits: to renew OO inheritance in a hacker style discussion

[Dan Sugalski]

At 9:15 AM -0800 2/17/04, Larry Wall wrote:
On Tue, Feb 17, 2004 at 11:39:07AM -0500, Dan Sugalski wrote:
: At 8:30 AM -0800 2/17/04, Larry Wall wrote:
: So perhaps we need a different word than does to indicate that
: you want to include the Dog interface without including the Dog
: implementation.  Perhaps we can do that with is like(Dog) or some
: such if we don't want to Huffman code it shorter.  Then people who
: believe only in Interfaces can use the same underlying system-defined
: Roles without compromising their Java-bedeviled value system.  :-)
:
: You could, I suppose, use implements to note that a class provides
: the role all by itself, and imports to note that it brings in the
: role from an external source.
I think you are using the word role to mean implementation.
I prefer to use role to mean both interface and implemention.
Well, I usually use role to mean the interface, but that's a separate 
issue. (Implementation is, after all, just a matter of implementation)

I think it may be wise to separate the implementation and the 
interface -- If I had to guess I'd say the declaration of interface 
conformation is going to be a lot more common, at least in class 
declarations.

Roles'll get thrown on individual variables and values, sure, but 
when I'm writing a class (Yes, I know, but lets suspend disbelief for 
a moment :) I'm not generally going to put a pre-existing role on a 
class--I'll just inherit from the darned thing. Roles, when working 
with whole classes, will be more a declaration of interface than an 
importation of implementation. (That, I suppose, argues for two 
separate sets of syntax, one for runtime role aquisition and another 
for class definition, but I think I won't go there)

Either way I don't care what the keywords are, I just think that 
there ought to be two, and it should be clear that interface and 
implementation are different. Besides, *someone* will want to throw a 
role on an object but use an alternate implementation. Think I won't 
go there either, though.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: The Sort Problem (was: well, The Sort Problem)

[Dan Sugalski]

At 11:52 PM -0700 2/12/04, Luke Palmer wrote:
But it needs some major syntax work so it can feel more like it's a part
of the language instead of a library function.  Not, mind, that I think
Perl's syntax needs to be changed at all to accommodate.
Since everyone's well past mad here and deep into drug-induced brain 
damage territory...

If you're *really* looking to get fancy, why not just allow the sort 
specification to be done with SQL? Comfortable, well-understood, 
already has a decade or so of stupid things welded into it (so 
everyone can stop trying to think up new stupid things to weld in), 
and there are several grammars for it so it'd be no work to speak of 
for me.

Heck, you could even unify map, grep, and sort and, if you fed in a 
list of pair lists or hashes, return parts of each record^Wlist 
element rather than the whole thing.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [perl] The Sort Problem

[Dan Sugalski]

At 11:40 PM -0500 2/11/04, Joe Gottman wrote:
   This is unrelated to the problem you mentioned, but there is another
annoying problem with sort as it is currently defined.  If you have an
@array and you want to replace it with the sorted version, you have to type
@array = sort @array;
That would seem to be a place for more explicit, and specific, 
behaviour. Since we're going everything is an object then it's just 
a matter of:

   @array.sort_in_place;

and making sure that the array role provides the appropriate method.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Start of thread proposal

[Dan Sugalski]

 into the calling interpreter. The called interpreter will
block while the return data is copied back into the calling interpreter.
=item Inter-interpreter events will be provided

Interpreters will be able to post events to other interpreters.

=item Each interpreter will have a unique id

This ID will be independent of the process or OS thread, and will be
constant across the lifetime of the interpreter. Interpreter IDs
Imay be reused as interpreters are destroyed and recreated, and as
such are only guaranteed valid while an interpreter is in use.
(Note that we may decide to relax this requirement, but doing so
likely means moving to at least 64-bit integers to mark interpreter IDs)
=item Each interpreter show the same process id

All the interpreters within a process will share a process ID. On
those systems where each thread has its own unique ID (such as many
versions of Linux) Parrot will still report a single process ID for
all interpreters.
This process ID will be the ID of the process that first instantiated
Parrot.
=item Interpreter pools will share allocation pools

All the interpreters in an interpreter pool will share header and
memory allocation pools. This means that when there is more than one
interpreter in a pool the memory allocation and collection system
needs to be swapped out, as a copying collector is generally
untenable in a threaded environment.
As the allocation and collection system is a black box to user
programs and much of the interpreter internals, this isn't a big deal
outside of needing swappable allocation systems, the potential
issue of COW'd shared memory leaking, and the need to switch
allocation schemes mid-execution.
=item Each interpreter has a separate event queue

Some events, such as timers, may be interpreter-specific and, as
such, each interpreter has its own event queue.
=item Each interpreter pool has a shared event queue

Some events, such as IO callbacks, may not be interpreter-specific,
and can be serviced by any interpreter in the interpreter pool. For
these events, there is a pool-wide event queue.
=item PMCs are the coordination point for threads

That is, only PMCs are shared as such between threads. Strings,
specifically, are Inot shared between interpreters as such
=item All PMCs shared amongst interpreters in a pool must be marked shared

A PMC which is not marked shared may not be handed to another
interpreter. Parrot will prevent this from happening either by
marking the PMC as shared, or throwing an exception when the PMC is
placed in a spot where it may be shared but is not shareable.
=item All shared PMCs must have a threadsafe vtable

The first thing that any vtable function of a shared PMC must do is to
aquire the mutex of the PMCs in its parameter list, in ascending
address order. When the mutexes are released they are not required to
be released in any order.
=item Automatic PMC sharing will be provided

When a PMC is placed into a container which is shared (including
lexical pads and global namespaces) then that PMC will automatically
be marked as shared. It is acceptable for this to trigger an
exception if for some reason a PMC should not be shared between
interpreters.
PMCs are, by default, not shared. This avoids sharing overhead for
PMCs which are only used as temporaries and not shared. (Note that
this is dangerous, and may end up not being done, due to the sharing
of continuations)
=item All interpreter constructs in a pool are shareable

This means that a PMC or string may be used by any interpreter in a
pool. It additionally means that, if full sharing is enabled, that
any interpreter in a pool may invoke a continuation, assuming the
continuation is valid. (That is, a continuation taken at parrot's top
level. Continuations taken within vtable functions, user-defined ops,
or extension code may not be shareable)
=item The embedding API will allow posting events to a pool

Many events are interpreter-specific, often caused by one particular
interpreter requesting an async event that later completes.
=item The embedding API will allow posting events to an interpreter

For events that don't have to go to any particular interpreter, they
can go into the pool's event loop.
=item The embedding API will allow calling a parrot sub with a pool

In those cases where there is an interpreter pool, embedders may call
a parrot sub using the pool as a whole, rather than an individual
interpreter, to run the sub. In that case Parrot may either choose a
dormant interpreter (if there is one) or create a new interpreter in
the pool to run the subroutine.
When the sub is done, Parrot may either cache the created
interpreter or destroy it as it needs to, though in no case will
Parrot ever leave a pool with no interpreters at all.
=back

--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears

Re: This week's summary

[Dan Sugalski]

At 12:36 PM -0500 1/13/04, Uri Guttman wrote:
  TP6S == The Perl 6 Summarizer [EMAIL PROTECTED] writes:

  TP6S   Congratulations Dan

  TP6S Melvin Smith offered his congratulations to Dan for the
  TP6S first commercial use of Parrot. I think I can safely say we
  TP6S all echo those congratulations.
shouldn't that be production use?
It's not in production yet--we've just had the first big working 
proof-of-concept release. While it was important (showed that it was 
a viable option, and most of the runtime library is implemented) I'm 
definitely not ready to even beta this, let alone roll it out on the 
floor.

Don't worry, when that happens I'll make a lot of noise. :)
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Reminder: The EU constitution's off-topic

[Dan Sugalski]

And should stay off-list, thanks.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Perl 6 using Perl 5 modules

[Dan Sugalski]

At 6:56 PM -0800 12/23/03, Larry Wall wrote:
But maybe I'm hoping for too much--it's hard to imagine how this kind
of bless could work in-place to (in effect) annotate a data structure
with handler classes.
This is actually pretty darned trivial with the current architecture, 
so both composed objects and Oh, look, this thingie... it's an 
object too! type objects are easily doable.

Currently I'm not seeing any technical reason for perl 5 style 
objects to be anything other than, well, perl 5 style objects. 
Something could come up, I suppose, but I'd not expect it to.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Why multi-by-default is a bad idea (was: Re: Object Order of Precedence (Was: Vocabulary))

[Dan Sugalski]

At 2:21 PM -0800 12/20/03, Larry Wall wrote:
On Sat, Dec 20, 2003 at 12:41:10PM -0800, Jonathan Lang wrote:
: So what happens if more than one of the candidates is tagged as the
: default?  The same thing as if none of them was?  This could happen if
: both Predator and Pet have declared their 'feed' methods as the default. 

Could blow up, or look for a more generic default that isn't in a tie.
The latter seems more fail-soft, since something else of the same name
is likelier to know what to do than some random exception handler in
who-knows-what dynamic context.
It's straightforward enough to pitch an exception at sub definition 
time. That'll be a compile time error generally, which is likely 
fine, or an eval/do/require runtime error, which is also fine as 
anyone doing runtime code loading should be ready to catch 
compile-class errors. Installing new subs symbolically into symbol 
tables might be a bit more problematic, but mostly syntactically so 
it's not my problem. :)

: What about making multi dispatches the assumed behavior, with a Cunique
: keyword to explicitly shut it off (for the sake of optimization)?  That
: is, replace the Cmulti keyword used to define routines that participate
: in multiple dispatching with a Cunique keyword used to define routines
: that don't. 

Now that's...an *interesting* idea.

But I'm getting sidetracked.  The underlying question is whether multi
should be the default.  And that's still an interesting idea regardless
of the syntax.
And, IMAO, a very, *very* bad one. I dunno about you, but when I 
install a sub into a symbol table I fully expect it to be the only 
one of that name, and if there's an existing sub of that name I 
expect it to be replaced, not supplemented. (Or have a warning and/or 
error pitched, that's fine too)

This also makes language interoperability somewhat tricky, as it is 
*not* the default for any other language in our class, including perl 
5. That means either we change the default behaviour of perl 5 (which 
strikes me as bad) or we retain the base default behavior of each 
language in which case you end up with subs that may or may not be 
multi depending on the order of inclusion of modules. (if you include 
two modules that define the same sub in the same namespace, one with 
multi-by-default and one without)

Another unexplored question is how and whether to open up multiple
dispatch to more scopes than just the first one in which you find
the name
I can do lexically-scoped multi-method dispatch tables, the same way 
we're going to do lexically-scoped method caches, but I'm not sure 
it's a wise idea. (Well... I'm pretty sure it's an unwise one, but 
I'm unsure of how correct that is)

Could we just leave it as global multimethod subs and methods, and 
package-local multimethod subs and methods for now? We can always 
bring in the more insane^Wexpansive version later, in perl 6.2 or 
something, once we see how things are going and how people are 
dealing with it.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Vocabulary

[Dan Sugalski]

At 9:16 AM -0800 12/12/03, Larry Wall wrote:
On Fri, Dec 12, 2003 at 04:23:02AM -0700, Luke Palmer wrote:
: - property
:   An out-of-band sticky note to be placed on a single object.
: Used with Cbut.
Maybe applied with?

: - trait
:   A compile time sticky note to be placed on a wide variety of things.
: Used with Cis.
Fine.  (Though I like to hyphenate compile-time when it's an adjective,
and not when it's a noun.  Same for run-time, just to be consistent.)
I would really, *really* like to kill the whole It's a sticky note! 
metaphor dead. If I understand the changes proposed in properties as 
part of the whole shift to roles thing they aren't anything like 
sticky notes at all, as they dynamically subclass the object.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Anonymous Multi's? [was Re: Control flow variables]

[Dan Sugalski]

On Thu, 20 Nov 2003, Dave Whipp wrote:

 Larry Wall [EMAIL PROTECTED] wrote:
  Also, since multi is orthogonal to naming ...

 So I'm wondering what the correct syntax is to grab a reference to a group
 of multi-somethings.

While Larry will probably weigh in on this, I'd rather you not actually be
able to do this, at least not to start with. And definitely not the
anonymous version. Maybe for perl 6.2 or 6.4.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Control flow variables

[Dan Sugalski]

On Tue, 18 Nov 2003, Simon Cozens wrote:

 Luke Palmer:

  That's illegal anyway.  Can't chain statement modifiers :-)

 Bah, should be able to!

Will be able to.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Control flow variables

[Dan Sugalski]

On Tue, 18 Nov 2003, Simon Cozens wrote:

 [EMAIL PROTECTED] (Dan Sugalski) writes:
   Luke Palmer:
That's illegal anyway.  Can't chain statement modifiers :-)
  Will be able to.

 I thought as much; Perl 6 will only be finally finished when the biotech
 is sufficiently advanced to massively clone Larry...

Not because of this. It's easier to allow it than not allow it.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Control flow variables

[Dan Sugalski]

On Tue, 18 Nov 2003, Simon Cozens wrote:

 [EMAIL PROTECTED] (Austin Hastings) writes:
  This is what I was talking about when I mentioned being able to do:
cleanup .= { push @moves: [$i, $j]; }

 This reminds me of something I thought the other day might be useful:

 $cleanup = bless {}, class {
 method DESTROY { ... }
 };

 Of course, it probably wouldn't work in this context because you couldn't
 guarantee that the destructor will be called at the point of loop exit, but I
 like the anonymous class syntax anyway.

 $cleanup = bless {}, class : impatient {
 method DESTROY { ... }
 };

That'll probably do it, at the expense of extra runtime block exit
overhead until the object dies. If you just want a block exit action,
then:

 add_block_exit_action(\foo);

or something similar will do it. (Though we could add new syntax for it if
you really want... :-)

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

RE: Control flow variables

[Dan Sugalski]

On Tue, 18 Nov 2003, Austin Hastings wrote:

 This seems excessive, but easily discarded during optimization. On the other
 hand, I don't trust the last statement evaluated behavior for loops, since
 the optimizer could very well do surprising things to loop statements.
 (Likewise, however, for scalar control structures.)

This shouldn't be a problem. If there's potential ambiguity then the
optimization can't be applied. Modulo optimizer bugs you'll be fine.

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Vector dot Vectoria

[Dan Sugalski]

On Wed, 5 Nov 2003, Doug McNutt wrote:

 I am officially retired with some time but I have yet to process my
 first CVS file and, though I do C, there is a long learning curve for
 this guy who started when FORTRAN was a pup. Is anyone interested enough
 to encourage me? What can I do? I run Mac-Darwin and Linux.

Well, I'm neither a mathematician nor a physicist (and I don't even play
one on TV) but I can really use folks who are or were. If you're willing,
subscribe to the internals list ([EMAIL PROTECTED]) and
we'll see what we can do with you. :)

Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: The Block Returns

[Dan Sugalski]

On Fri, 3 Oct 2003, Simon Cozens wrote:

 [EMAIL PROTECTED] (Austin Hastings) writes:
  eval($block) if defined $block;

 I prefer $block.compile.run to eval()

They're not quite equivalent -- I think eval's still wrapping a try/catch
around the call.

Dan

Re: The Block Returns

[Dan Sugalski]

On Thu, 2 Oct 2003, Mark A. Biggar wrote:

 Austin Hastings wrote:

  But that imposes Ceval()/C pretty frequently. Better to provide
  some lower-level hackish way to agglutinate Blocks.


 Isn't this one of the prime examples of why CPS is being use, it allows
 for Tail Recursion Optimization.  With TRO all your worries about
 overhead do to the wrap go away.

This isn't why CPS is being used under the hood. (Nothing in perl 6
propmted CPS) I wouldn't necessarily count on being able to do tail calls
here either, as they potentially alter the semantics, or at least the
introspectable environment, of the program as they make frames go away.

Dan

Re: The Block Returns

[Dan Sugalski]

At 11:55 PM +0100 10/3/03, Piers Cawley wrote:
Dan Sugalski [EMAIL PROTECTED] writes:

 On Thu, 2 Oct 2003, Mark A. Biggar wrote:

 Austin Hastings wrote:

  But that imposes Ceval()/C pretty frequently. Better to provide
  some lower-level hackish way to agglutinate Blocks.
 Isn't this one of the prime examples of why CPS is being use, it allows
 for Tail Recursion Optimization.  With TRO all your worries about
 overhead do to the wrap go away.
 This isn't why CPS is being used under the hood. (Nothing in perl 6
 propmted CPS) I wouldn't necessarily count on being able to do tail calls
 here either, as they potentially alter the semantics, or at least the
 introspectable environment, of the program as they make frames go away.
I'm vaguely hoping that modules will be able to declare that they
don't need to access a 'strict' caller and that they'll be happy
with a return from caller that skips any tail calls. Then, if the
Perl 6 compiler sees that all modules in play have declared
themselves in this fashion it'll use optimized tail calls. However,
thinking about that I'm not entirely sure how it could be done with a
single pass compiler.
I think it's reasonable to allow you to mark your subs as being able 
to be tail-called out of. Subs with no lexical variables should be 
safe to call out of as well, though that's a bit dodgier. OTOH, it's 
not like too many folks walk up their call chain.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Pondering parameterized operators

[Dan Sugalski]

On Fri, 26 Sep 2003, Austin Hastings wrote:

 How can I conveniently pass an extra parameter to a historically binary
 operator?

If it's one of the 'base' binary operators (addition, subtraction, and 
whatnot) you don't.

Dan

Re: object property syntax

[Dan Sugalski]

On Thu, 25 Sep 2003, Luke Palmer wrote:

 Todd W. writes:
  I have a question/request concerning perl6 object properties.
 
 Rather, attributes.  Properties are out-of-band data attached to a
 particular object.

FWIW, attribute and property are two words that have a meaning that 
shifts depending on what language you're talking about. IIRC, .NET 
languages have them exactly reversed from perl 6's usage...

Dan

Re: Parrot 0.0.11 Doubloon Released!

[Dan Sugalski]

At 9:28 PM +0200 9/20/03, Tels wrote:
-BEGIN PGP SIGNED MESSAGE-

Moin,

At long last, Parrot-0.0.11 Doubloon has been released!
This begs the question(s):

I know what BASIC means, but what the hell is a PCM and what is a IMCC
supposed to mean? And what is a CPS? The FAQ doesn't cover this...
PMC is Pulse Code Modulation, a clever trick to encode digital data 
on analog signals. (Well, OK, quantized data--it doesn't really have 
to be digital) Luckily Parrot doesn't have to deal with that. :)

I'll get the rest into the Glossary. (PMC too, if it's not there, 
though I think that it is)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Parrot 0.0.11 Doubloon Released!

[Dan Sugalski]

At 5:35 PM -0700 9/20/03, Steve Fink wrote:
On Sep-20, Steve Fink wrote:
 At long last, Parrot-0.0.11 Doubloon has been released!
And so has Parrot-0.0.11.1, for those of you who want correct native
bytecode tests!
http://cpan.perl.org/authors/id/S/SF/SFINK/parrot-0.0.11.1.tar.gz

Hmm... for symmetry, I'm now thinking I ought to have called it
parrot-0.00.11.1.tar.gz.
And all we need now is a 0.0.11.2, with patches to allow four-element 
version numbers...
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Next Apocalypse

[Dan Sugalski]

On Thu, 18 Sep 2003, Andy Wardley wrote:

 chromatic wrote:
  The thinking at the last design meeting was that you'd explicitly say
  Consider this class closed; I won't muck with it in this application
  at compile time if you need the extra optimization in a particular
  application.
 
 In Dylan, this is called a sealed class.  It tells the compiler that it's 
 safe to resolve method names to slot numbers at parse time, IIRC.  Seems
 like a nice idea.

We'll probably have an optimizer setting for this so you can declare 
classes sealed at the end of compilation. Parrot'll have to have a means 
of yelling loudly (and probably throwing a fatal exception) if you try and 
alter a sealed class at runtime.

This'll likely be a language-dependent setting, as some languages will 
seal classes by default, which makes some amount of sense in some 
circumstances.

Dan

Re: Next Apocalypse

[Dan Sugalski]

On Tue, 16 Sep 2003 [EMAIL PROTECTED] wrote:

 On Mon, 15 Sep 2003, Dan Sugalski wrote:
   Great. But will it also be possible to add methods (or modify them)
   to an existing class at runtime?
 
  Unless the class has been explicitly closed, yes.
 
 That strikes me as back-to-front.
 
 The easy-to-optimise case should be the easy-to-type case; otherwise a lot
 of optimisation that should be possible isn't because the programmers are
 too inexperienced/lazy/confused to put the closed tags in.

It would, in fact, be back-to-front if performance was the primary 
goal. And, while it is *a* goal, it is not *the* goal.

From Parrot's standpoint, it doesn't make much difference--once you start 
spitting out assembly you can be expected to be explicit, so it's a matter 
of what the language designer wants. While Larry's the ultimate arbiter, 
and I am *not* Larry, generally he favors flexibility over speed as the 
default, especially when you can get it at the current speed (that is, 
perl 5's speed) or faster. You don't lose anything over what you have now 
with that flexibility enabled, and if you want to restrict yourself for 
the extra boost, you can explicitly do that.

Then again, he may also decide that things are open until the end of 
primary compilation, at which point things are closed--you never know... 
:)

Dan

Re: Next Apocalypse

[Dan Sugalski]

On Tue, 16 Sep 2003, Ph. Marek wrote:

  You can, of course, stop even potential optimization once the first I can
  change the rules operation is found, but since even assignment can change
  the rules that's where we are right now. We'd like to get better by
  optimizing based on what we can see at compile time, but that's a very,
  very difficult thing to do.

 How about retaining some debug info, (line number come to mind), but only at 
 expression level??

This is insufficient, since many (potentially most) optimizations result 
in reordered, refactored, moved, and/or mangled code that doesn't have a 
line-for-line, or expression-for-expression, correspondence to the 
original. If it did, this would all be much easier.

The alternative, of course, is to not apply those transforms, but then 
you're left with pretty much no optimizations.

Dan

Re: Next Apocalypse

[Dan Sugalski]

On Sun, 14 Sep 2003, Gordon Henriksen wrote:

 On Saturday, September 13, 2003, at 11:33 , [EMAIL PROTECTED] 
 wrote:
 
  On Sat, 13 Sep 2003, Luke Palmer wrote:
 
  Of course having a no subclasses tag means the compiler can change a 
  method call into a direct subroutine call, but I would hope that method 
  calling will be fast enough that it won't need to.
 
 A strategy to actually keep that optimization, and apply it to much more 
 code, would be that the JIT compiler could optimize for the case that 
 there are no known subclasses, and pessimize that only if a subclass 
 were later loaded.
 
 I think this is one of the features Leo's been on about with respect to 
 notifications.

That's one of the reasons notifications were designed in, yes. There's a 
growing body of interesting work on what's essentially disposable 
or partially-useful optimizations. Given the dynamic nature of most of the 
languages we care about for parrot, throwaway optimizations make a lot of 
sense--we can build optimized versions of functions for the current 
structure, and redo them if the structure changes.

This isn't entirely an easy task, however, since you can't throw away or 
redo a function/method/sub/whatever that you're already in somewhere in 
the call-chain, which means any optimizations will have to be either 
checked at runtime or undoable when code is in the middle of them. (Which 
is a decidedly non-trivial thing, and impossible in general, though 
possibly not in specific cases)

I don't see any reason to not allow marking a class as final (though 
that's not hugely useful), closed (which is far more useful), or declared 
objects as exact types rather than subtypable. (Which is, in conjunction 
with closing a class, hugely useful)

Which is to say that marking a class as unenhanceable and Foo variables as 
holding *only* objects of type Foo and not child classes, gets us a lot 
more than marking a class as final. (Which does the same thing, but 
globally, and not necessarily usefully)

Dan

Re: Next Apocalypse

[Dan Sugalski]

On 13 Sep 2003, Jonadab the Unsightly One wrote:

 Dan Sugalski [EMAIL PROTECTED] writes:
 
  Next Apocalypse is objects, and that'll take time. 
 
 Objects are *worth* more time than a lot of the other topics.
 Arguably, they're just as important as subroutines, in a modern
 language.

Oh, I dunno -- it's not like there's all that much to objects, but I might 
be a touch biased here. (I'd say they're worth more time because people 
get so worked up over them, not because they're particularly complex, 
complicated, or difficult)
 
 Speaking of objects...  are we going to have a built-in object forest,
 like Inform has, where irrespective of class any given object can have
 up to one parent at any given time,

Multiple parent classes, yes. Parent objects, no. (Unless you consider 
composition of objects from multiple parent classes with each class having 
instance variables in the objects as multiple parent objects. In which 
case the answer's yes)

 which can change at runtime, 

Well, the inheritance hierarchy for a class can change at runtime, though 
we'd really rather you didn't do that, so I suppose you could do it for 
individual objects--they'd just get a transparent singleton class that 
you'd mess around with from there. I think I may be missing your point.

 and
 be able to declare objects as starting out their lives with a given
 parent object, move them at runtime from one parent to another (taking
 any of their own children that they might have along with them), fetch
 a list of the children or siblings of an object, and so forth?

Erm I don't think so. I get the feeling that Inform had a different 
view of OO than we do.

Dan

Re: Next Apocalypse

[Dan Sugalski]

On Mon, 15 Sep 2003, Piers Cawley wrote:

 Luke Palmer [EMAIL PROTECTED] writes:
  Also, the standard library, however large or small that will be, will
  definitely be mutable at runtime.  There'll be none of that Java you
  can't subclass String, because we think you shouldn't crap.
 
 Great. But will it also be possible to add methods (or modify them)
 to an existing class at runtime? 

Unless the class has been explicitly closed, yes.

Dan

Re: Next Apocalypse

[Dan Sugalski]

On 15 Sep 2003, Simon Cozens wrote:

 [EMAIL PROTECTED] (Piers Cawley) writes:
  Great. But will it also be possible to add methods (or modify them)
  to an existing class at runtime? You only have to look at a Smalltalk
  image to see packages adding helper methods to Object and the like
 
 People get upset when CPAN authors add stuff to UNIVERSAL:: :)

Yeah, but does that actually *stop* anyone? :-P

Dan

Re: Macro arguments themselves

[Dan Sugalski]

On Mon, 15 Sep 2003, Piers Cawley wrote:

 Luke Palmer [EMAIL PROTECTED] writes:
 
  Alex Burr writes:
  In theory you could write one as a perl6 macro, although it would be
  more convenient if there was someway of obtaining the syntax tree of a
  previously defined function other than quoting it (unless I've missed
  that?).  
 
  There is a large class of cool optimizations possible when you combine
  notifications with storing the syntax tree at runtime, so I think it
  will be possible to get the syntax tree of a previously defined
  function.  Probably just a method on Code objects.
 
 I'll be very disappointed if you can't get the syntax tree at
 runtime, though I have the feeling that it might require a
 compilation switch of some sort.

The syntax tree will be stored by default, though it will be strippable 
from the bytecode files for space and/or paranoia reasons.

Dan

Re: Next Apocalypse

[Dan Sugalski]

On Mon, 15 Sep 2003, Austin Hastings wrote:

 --- Dan Sugalski [EMAIL PROTECTED] wrote:
  This isn't entirely an easy task, however, since you can't throw away
  or redo a function/method/sub/whatever that you're already in 
  somewhere in the call-chain, which means any optimizations will 
  have to be either checked at runtime or undoable when code is in 
  the middle of them.
 
 Why is this?

Because there are some assertions that can lead the optimizer to make some 
fundamental assumptions, and if those assumptions get violated or 
redefined while you're in the middle of executing a function that makes 
use of those assumptions, well...

Changing a function from pure to impure, adding an overloaded operator, or 
changing the core structure of a class can all result in code that needs 
regeneration. That's no big deal for code you haven't executed yet, but if 
you have:

a = 1;
b = 12;
foo();
c = a + b;

and a and b are both passive classes, that can get transformed to

a = 1;
b = 12;
foo();
c = 13;

but if foo changes the rules of the game (adding an overloaded + to a or
b's class) then the code in that sub could be incorrect.

You can, of course, stop even potential optimization once the first I can 
change the rules operation is found, but since even assignment can change 
the rules that's where we are right now. We'd like to get better by 
optimizing based on what we can see at compile time, but that's a very, 
very difficult thing to do.

Dan

Re: Next Apocalypse

[Dan Sugalski]

At 3:30 PM -0600 9/15/03, Luke Palmer wrote:
The problem is we need to somehow un-optimize while we're running.  That
is most likely a very very hard thing to do, so another solution is
probably needed.
It is, indeed, a very hard problem. It's solvable if you disallow 
several classes of optimization (basically ones that involve code 
motion) that make things less than optimal. You can also scatter a 
lot of tests for invalidations and have the notification system set 
the flags, though there are still code motion problems there. (Loops 
are particularly troublesome)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Next Apocalypse

[Dan Sugalski]

At 5:07 PM -0500 9/15/03, Jonathan Scott Duff wrote:
On Mon, Sep 15, 2003 at 03:30:06PM -0600, Luke Palmer wrote:
 The focus here, I think, is the following problem class:

 sub twenty_five() { 25 }# Optimized to inline
 sub foo() {
 print twenty_five;  # Inlined
 twenty_five := { 36 };
 print twenty_five;  # Uh oh, inlined from before
 }
 The problem is we need to somehow un-optimize while we're running.  That
 is most likely a very very hard thing to do, so another solution is
 probably needed.
A naive approach would be to cache the names and positions of things
that are optimized such that when one of the cached things are
modified, the optimization could be replaced with either another
optimization (as in the case above) or an instruction to execute some
other code (when we can't optimize the change).
That doesn't work in the face of code motion, reordering, or 
simplification, unfortunately. :(
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Next Apocalypse

[Dan Sugalski]

On Tue, 9 Sep 2003, Jonathan Scott Duff wrote:

 
 This is mostly just a gratuitous message so that Piers has something
 to talk about in the next summary ;-), but when's the next
 Apocalypse due out?

Well, I don't know if Leon (Hi Piers!) has better information than I do,
but the short answer is Not for a while. Next Apocalypse is objects, and
that'll take time. Damian may well get E7, formats, out sooner, but he's
on vacation for the first time in too long, so he'd better not answer for
a few weeks.  :)

Dan

Re: Apocalypses and Exegesis...

[Dan Sugalski]

On 14 Aug 2003, Alberto Manuel Brandão Simões wrote:

 Hi
 
 Apocalypses and Exegesis are not an 'official' specification for Perl6,
 I mean, they are subject to change. Is there any idea when will we have
 a freeze on the syntax and features for perl6?

Sometime after perl 5's syntax and features freeze, I expect. When *that* 
happens is anyone's guess. :)

More seriously, things will get less mutable as the implementation 
progresses, and I expect as we come up to a beta release things will be 
pretty stable, barring changes because things are unimplementable or 
problematic. That should happen over the next 6-12 months, time willing.

Dan

Re: Implicit parameter aliases

[Dan Sugalski]

At 1:02 PM -0700 8/5/03, Dave Whipp wrote:
Can I discriminate on parameter names using multi subs?
Nope. Named parameters don't participate in MMD.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Dispatching, Multimethods and the like

[Dan Sugalski]

At 10:37 AM -0400 6/17/03, Adam Turoff wrote:
On Mon, Jun 16, 2003 at 06:31:54PM -, Dan Sugalski wrote:
 For methods, each object is ultimately responsible for deciding what to
 do when a method is called. Since objects generally share a class-wide
 vtable, the classes are mostly responsible for dispatch. The dispatch
 method can, if it wants, do *anything*.
Hm.  Ruby has unbound methods and per-object method binding.  How
does that impact Parrot's built-in dispatching behavior(s)?
Unbound methods are just functions, and per-object methods create a 
transparent subclass for just the object being overridden. (Which is 
how Ruby does it, FWIW)

  Core engine support will be in for this, since we don't want everyone to
 have to bother writing code for it all. Duplicate code. Bleah. We'll
 also provide method caches so we have some hope of not being horribly
 slow.
Hm.  Maybe the solution here isn't to fob off *all* dispatching to the
core or the program, but have loadable dispatching behaviors, much like
loadable datatypes and opcodes...
Right. Hence the points of abstraction--so there's a well-defined 
place to take control, along with a well documented, if not actually 
sane, default. There's a lot you can do with sub/method wrapping as 
well, which there's language support for in perl 6.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Dispatching, Multimethods and the like

[Dan Sugalski]

In [EMAIL PROTECTED] Adam Turoff wrote:
 Damian just got finished his YAPC opening talk, and managed to allude
 to dispatching and autoloading.
 
 As it *appears* today, regular dispatching and multimethod dispatching
 are going to be wired into the langauge (as appropriate).  Runtime
 dispatch behavior will continue to be supported, including things like
 AUTOLOADER and the like.
 
 As of January, the thinking is sub DISPATCH {} will handle runtime
 dispatching behaviors, including autoloading, but easily accomodating
 value-based dispatching, AOP style pre/post methods, and whatnot.  
 
 Unfortunately, Damian said that the design team isn't saying much 
 about this, because the semantics aren't quite worked out yet, 
 especially with the interaction between autoloading and other dynamic 
 dispatching behaviors.

 Yes, this is a *big* issue.

It definitely is.

I can't speak for Perl 6 the language, but I can speak for Parrot, so I 
can tell you what semantics will be available (though not necessarily 
exposed) to the compiler.

For methods, each object is ultimately responsible for deciding what to 
do when a method is called. Since objects generally share a class-wide 
vtable, the classes are mostly responsible for dispatch. The dispatch 
method can, if it wants, do *anything*. However, as some degree of 
predictability is nice, the current plan is that classes will:

  1) Look for the method in the class or parent. If found, it's 
dispatched to. (This method may be defined as a multimethod in the class, 
in which case MMD is used to determine which method of the set *in the 
class only* is used)
  2) Look for an AUTOLOAD method in the class or parent. If found, we 
dispatch to it.
  3) Look for a MMD version of the method outside of any class. If found, 
do MMD

Core engine support will be in for this, since we don't want everyone to 
have to bother writing code for it all. Duplicate code. Bleah. We'll 
also provide method caches so we have some hope of not being horribly 
slow.

By default, the system and class MMD will do class-based dispatching 
only, deciding on which method to call based on the types of the 
parameters. Both the class MMD method *and* the system MMD method may be 
overridden if someone wants to install their own MMD scheme, though 
overriding system-wide MMD stuff is always a dodgy thing. (Though no 
more than any other overridden systemwide thing, I expect)

Will perl 6 support this? Dunno. Will it call for a different scheme? It 
well might. Can a language completely skip the MMD stuff? It can if it 
chooses, yes. What name will the dispatch sub be? Beats the heck out of 
me, but then that's syntax and I don't do syntax. :)

Re: How shall threads work in P6?

[Dan Sugalski]

At 11:09 AM -0800 3/31/03, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
 At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
 On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
 I've been thinking about closures, continuations, and coroutines,
 and
 one of the interfering points has been threads.
 
 What's the P6 thread model going to be?
 
 As I see it, parrot gives us the opportunity to implement
 preemptive
 threading at the VM level, even if it's not available via the OS.
 
 I think we should consider cooperative threading, implemented using
 continuations.  Yielding to another thread would automatically
 happen when a thread blocks, or upon explicit request by the
 programmer.
 
 It has many advantages:
 And one disadvantage:

 Dan doesn't like it. :)

 Well, there are actually a lot of disadvantages, but that's the only
 important one, so it's probably not worth much thought over alternate
 threading schemes for Parrot at least--it's going with an OS-level
 preemptive threading model.
 No, this isn't negotiable.
More information please.
There isn't any, particularly. We're doing preemptive threads. It 
isn't up for negotiation. This is one of the few things where I truly 
don't care what people's opinions on the matter are.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: How shall threads work in P6?

[Dan Sugalski]

At 7:35 AM -0800 4/1/03, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
 At 11:09 AM -0800 3/31/03, Austin Hastings wrote:
 --- Dan Sugalski [EMAIL PROTECTED] wrote:
   At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
   On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
   I've been thinking about closures, continuations, and
 coroutines,
   and
   one of the interfering points has been threads.
   
   What's the P6 thread model going to be?
   
   As I see it, parrot gives us the opportunity to implement
   preemptive
   threading at the VM level, even if it's not available via the
 OS.
   
   I think we should consider cooperative threading, implemented
 using
   continuations.  Yielding to another thread would automatically
   happen when a thread blocks, or upon explicit request by the
   programmer.
   
   It has many advantages:
 
   And one disadvantage:
 
   Dan doesn't like it. :)
 
   Well, there are actually a lot of disadvantages, but that's the
 only
   important one, so it's probably not worth much thought over
 alternate
   threading schemes for Parrot at least--it's going with an
 OS-level
   preemptive threading model.
 
   No, this isn't negotiable.
 
 More information please.
 There isn't any, particularly. We're doing preemptive threads. It
 isn't up for negotiation. This is one of the few things where I truly
 don't care what people's opinions on the matter are.
Okay, but what does OS-level mean? Are you relying on the OS for
implementing the threads (a sub-optimal idea, IMO) or something else?
Yes, we're using the OS-level threading facilities as part of the 
threading implementation.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: How shall threads work in P6?

[Dan Sugalski]

At 8:13 PM +0200 3/31/03, Matthijs van Duin wrote:
On Mon, Mar 31, 2003 at 07:45:30AM -0800, Austin Hastings wrote:
I've been thinking about closures, continuations, and coroutines, and
one of the interfering points has been threads.
What's the P6 thread model going to be?

As I see it, parrot gives us the opportunity to implement preemptive
threading at the VM level, even if it's not available via the OS.
I think we should consider cooperative threading, implemented using 
continuations.  Yielding to another thread would automatically 
happen when a thread blocks, or upon explicit request by the 
programmer.

It has many advantages:
And one disadvantage:

Dan doesn't like it. :)

Well, there are actually a lot of disadvantages, but that's the only 
important one, so it's probably not worth much thought over alternate 
threading schemes for Parrot at least--it's going with an OS-level 
preemptive threading model.

No, this isn't negotiable.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Perl and *ML

[Dan Sugalski]

I think that the issue here isn't so much good perl support for XML 
as it is good support for attributed DAGs, something which would be 
of general good use for perl, since the ASTs the parser feeds to the 
compiler will ultimately be DAGs of a sort.

So, rather than jumping on the XML [insert verb here]! bandwagon, 
perhaps we'd be better served figuring out what would be useful 
operations and support for/on DAGs and suchlike things?
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Perl and *ML

[Dan Sugalski]

At 4:47 PM +0100 3/26/03, Robin Berjon wrote:
Dan Sugalski wrote:
I think that the issue here isn't so much good perl support for XML 
as it is good support for attributed DAGs, something which would be 
of general good use for perl, since the ASTs the parser feeds to 
the compiler will ultimately be DAGs of a sort.

So, rather than jumping on the XML [insert verb here]! bandwagon, 
perhaps we'd be better served figuring out what would be useful 
operations and support for/on DAGs and suchlike things?
Fast and efficient graphs of all sorts would be very useful. A way 
to define a complex graph of interlinked arbitrary objects while 
being reasonable on memory and good with GC would be a definitive 
big win, especially if it can be lazy. Especially with nice ways to 
write visitors and easy searches in the graph based on object 
properties (but I could be asking for too much ;).
Probably a bit much, yep. :) I'd be happy with simple graph 
representation, annotation, and traversal. And for my purposes a DAG 
is sufficient. Loops are terribly annoying to have to deal with.

DAGs wouldn't enough though, most XML tree representations aren't 
really trees, they're very cyclic. Some automata can treat a stream 
of events as a B-Tree being visited, but those are rather rare 
currently.
I was under the impression XML was very much a tree, and didn't do 
loops. Am I missing something here? (I don't, in general, do XML)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: list manners question

[Dan Sugalski]

At 8:32 AM -0800 3/26/03, Paul wrote:
I wonder at times, however, if a simple vote of yea or nay might
actually count for something here.
Plain yes or no? Not generally, no, unless someone's actually looking 
for a count or vote.

Yes or no with explanation, especially when it's about things in the 
apocalypses, can have a lot of impact, so if you have more than a yes 
or no then there's a possibility.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: P6ML?

[Dan Sugalski]

At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote:
So, is anyone working on a P6ML, and/or is there any 
discussion/agreement of what it would entail?
I, for one, think it's a great idea, and the thought of altering perl 
6's grammar to make it a functional language is sheer genius, making 
the concepts behind ML more accessible to folks used to procedural 
languages. Darned good idea--I say start right away!
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: P6ML? [OT]

[Dan Sugalski]

At 11:52 AM -0800 3/25/03, Paul wrote:
--- Austin Hastings [EMAIL PROTECTED] wrote:
 --- Dan Sugalski [EMAIL PROTECTED] wrote:
  At 10:44 AM -0800 3/25/03, Michael Lazzaro wrote:
  So, is anyone working on a P6ML, and/or is there any
  discussion/agreement of what it would entail?
 
  I, for one, think it's a great idea, and the thought of altering
  perl 6's grammar to make it a functional language is sheer genius,
  making the concepts behind ML more accessible to folks used to
  procedural languages. Darned good idea--I say start right away!
 |==[*]|
Sarcasmeter?
lol -- I think my BS-o-meter just redlined, too
Heh. Sorry 'bout that. Bring it to OSCON and I'll get it fixed. :)

I think the original was an XML in perl 6 proposal of some sort. XML 
makes me twitch, though. Ick.

A (or is that an?) ML compiler for parrot'd be really cool, though.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: P6ML? [OT]

[Dan Sugalski]

At 12:47 PM -0800 3/25/03, Paul wrote:
|==[*]|
  Sarcasmeter?
 
 lol -- I think my BS-o-meter just redlined, too
 Heh. Sorry 'bout that. Bring it to OSCON and I'll get it fixed. :)
lol -- when/where is that? (Seems all I do here is ask dumb questions).
*sigh*
Portland Oregon, July 7-11. The 7th and 8th are tutorials, the 
conference proper is wednesday the 9th through friday the 11th. The 
conference is just down the street from Powell's (www.powells.com) 
which is possibly the single best, and certainly biggest, used 
bookstore in the US, if not the planet. Bring lots of money and a 
spare pair of suitcases.


 A (or is that an?) ML compiler for parrot'd be really cool, though.
Anything in Parrot is likely to be pretty cool. :)
I dunno. Can *anything* make INTERCAL cool? I think not! :-P
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: is static? -- Question

[Dan Sugalski]

At 12:05 PM -0600 3/24/03, Jonathan Scott Duff wrote:
On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
 The purpose of a state variable is to keep state across multiple calls
 to the same scope, so I'd say the proper semantics on closures is
 to treat the generation of a closure as a new block with new state 
properties.
 The most useful initialization semantics appear to be just in time,
 that is, on first actual call to the generated closure.  START time
 in my previous message, though I'm still unhappy with that name.
 FIRST would be better, but that's taken (this week).
ENTER?  Possibly with a corresponding LEAVE?
Argh, more semantics to deal with.

Since I'd as soon not encourage this, how about INSTANTIATE? Nice and 
long and therefore discouraging. :)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: is static? -- Question

[Dan Sugalski]

At 10:34 AM -0800 3/24/03, Larry Wall wrote:
On Mon, Mar 24, 2003 at 12:05:13PM -0600, Jonathan Scott Duff wrote:
: On Mon, Mar 24, 2003 at 09:34:23AM -0800, Larry Wall wrote:
:  The purpose of a state variable is to keep state across multiple calls
:  to the same scope, so I'd say the proper semantics on closures is
:  to treat the generation of a closure as a new block with new 
state properties.
:  The most useful initialization semantics appear to be just in time,
:  that is, on first actual call to the generated closure.  START time
:  in my previous message, though I'm still unhappy with that name.
:  FIRST would be better, but that's taken (this week).
:
: ENTER?  Possibly with a corresponding LEAVE?

Er, how would LEAVE detect that this was the *last* time you're ever
going to call this routine?
The only thing I can think of is to map it to the closure's DESTROY 
method and call it when the closure gets GC'd.

On the other hand, if we renamed FIRST and LAST to ENTER and LEAVE,
then FIRST would become available to mean my very first time...
Ahem.  Let us not dwell on the Freudian aspects of all this...
Put down that cigar, Larry...
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 12:00 AM + 3/20/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Matthijs Van Duin) writes:
 OK, I suppose that works although that still means you're moving the
 complexity from the perl implementation to its usage: in this case,
 the perl 6 parser which is written in perl 6
No, I don't believe that's what's happening. My concern is that at some
point, there *will* need to be a bootstrapped parser which is written in
some low level language, outputting Parrot bytecode, and it *will* need
to be able to reconfigure itself mid-match.
I think. I can't remember why I'm so convinced of this, and I'm too tired
to think it through with examples right now, and I might be wrong anyway,
but at least I can be ready with a solution if it proves necessary. :)
You may well be right--I don't think so,  but I'm not at my clearest 
either. I don't see that it'll be needed outside the initial 
bootstrap parser if at all, so I'm not too worried. (And the 
low-level language for it will probably be perl 5, since I'd far 
rather build something with a Parse::RecDescent grammar than a 
hand-nibbler in C)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 10:05 AM +0100 3/19/03, Matthijs van Duin wrote:
But.. say you have:

foo bar

Would would this be implemented?  When bar fails, it needs to 
backtrack into foo, which has already returned.  Are you saying 
every rule will be an explicit state machine?
By compile-time interpolation. foo isn't so much a subroutine as a 
macro. For this to work, if we had:

  foo: \w+?
  bar: [plugh]{2,5}
then what the regex engine *really* got to compile would be:

   (\w+?) ([plugh]{2,5})

with names attached to the two paren groups. Treating them as actual 
subroutines leads to madness, continuations don't quite work, and 
coroutines could pull it off if we could pass data back into a 
coroutine on reinvocation, but...

We do, after all, want this fast, right?
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 4:52 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 10:40:02AM -0500, Dan Sugalski wrote:
By compile-time interpolation. foo isn't so much a subroutine as 
a macro. For this to work, if we had:

  foo: \w+?
  bar: [plugh]{2,5}
then what the regex engine *really* got to compile would be:

   (\w+?) ([plugh]{2,5})

with names attached to the two paren groups. Treating them as 
actual subroutines leads to madness,
Ehm, Foo.test cannot inline Foo.foo since it may be overridden:

grammar Foo {
rule foo { \w+? }
rule bar { [plugh]{2,5} }
rule test { foo bar }
}
grammar Bar is Foo {
rule foo { alpha+? }
}
What you say is only allowed if I put is inline on foo.
At the time I run the regex, I can inline things. There's nothing 
that prevents it. Yes, at compile time it's potentially an issue, 
since things can be overridden later, but that's going to be 
relatively rare, and can be dealt with by selective recompilation.

By the time the regex is actually executed, it's fully specified. By 
definition if nothing else--you aren't allowed to selectively 
redefine rules in the middle of a regex that uses those rules. Or, 
rather, you can but the update won't take effect until after the end 
of the regex, the same way that you can't redefine a sub you're in 
the middle of executing. (And yes, I'm aware that if you do that 
you'll pick up the new version if you recursively call, but that 
won't work with regexes)

continuations don't quite work
Care to elaborate on that?  I'd say they work fine
There's issues with hypothetical variables and continuations. (And 
with coroutines as well) While this is a general issue, they come up 
most with regexes.

We do, after all, want this fast, right?
Ofcourse, and we should optimize as much as we can - but not 
optimize *more* than we can.  Rules need generic backtracking 
semantics, and that's what I'm talking about.
No. No, in fact they don't. Rules need very specific backtracking 
semantics, since rules are fairly specific. We're talking about 
backtracking in regular expressions, which is a fairly specific 
generality. If you want to talk about a more general backtracking 
that's fine, but it won't apply to how regexes backtrack.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 10:41 AM -0600 3/19/03, Jonathan Scott Duff wrote:
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
 By the time the regex is actually executed, it's fully specified. By
 definition if nothing else--you aren't allowed to selectively
 redefine rules in the middle of a regex that uses those rules. Or,
 rather, you can but the update won't take effect until after the end
 of the regex, the same way that you can't redefine a sub you're in
 the middle of executing. (And yes, I'm aware that if you do that
 you'll pick up the new version if you recursively call, but that
 won't work with regexes)
Are you implying that

$fred = rx/fred/;
$string ~~ m:w/ $fred { $fred = rx/barney/; } rubble /
won't match barney rubble?
Potentially, no. What, then, should happen if you do:

   $barney = rx/barney/;
   $string = barney rubble;
   $string ~~ m:w/ $barney { $barney = rx/fred/; } rubble /;
The regex shouldn't match, since you've invalidated part of the match 
in the middle.

I can potentially see constructs of the form $var be taken as 
indirect rule invocations and their dispatch left to runtime, 
complete with the potential for bizarre after-the-fact invalidations, 
but as regex rules in the regex stream rather than as generic code.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 5:38 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 11:09:01AM -0500, Dan Sugalski wrote:
At the time I run the regex, I can inline things. There's nothing 
that prevents it. Yes, at compile time it's potentially an issue, 
since things can be overridden later,
OK, but that's not how you initially presented it :-)
Then I wasn't clear enough, sorry. This is perl -- the state of 
something at compile time is just a suggestion as to how things 
ultimately work. The state at the time of is the only thing that 
really matters, and I shortcut.

you aren't allowed to selectively redefine rules in the middle of a 
regex that uses those rules. Or, rather, you can but the update 
won't take effect until after the end
I don't recall having seen such a restriction mentioned in Apoc 5.
I'll nudge Larry to add it explicitly, but in general redefinitons of 
code that you're in the middle of executing don't take effect 
immediately, and it's not really any different for regex rules than 
for subs.

While I'm a big fan of optimization, especially for something like 
this, I think we should be careful with introducing mandatory 
restrictions just to aid optimization.  (is inline will allow such 
optimizations ofcourse)
Actually, we should be extraordinarily liberal with the application 
of restrictions at this phase. It's far easier to lift a restriction 
later than to impose it later, and I very much want to stomp out any 
constructs that will force slow code execution. Yes, I may lose, but 
if I don't try...

My job, after all, is to make it go fast. If you want something 
that'll require things to be slow then I don't want you to have it. :)

There's issues with hypothetical variables and continuations. (And 
with coroutines as well) While this is a general issue, they come 
up most with regexes.
I'm still curious what you're referring to exactly.  I've outlined 
possible semantics for hypothetical variables in earlier posts that 
should work.
The issue of hypotheticals is complex.

We do, after all, want this fast, right?
Ofcourse, and we should optimize as much as we can - but not 
optimize *more* than we can.  Rules need generic backtracking 
semantics, and that's what I'm talking about.
No. No, in fact they don't. Rules need very specific backtracking 
semantics, since rules are fairly specific. We're talking about 
backtracking in regular expressions, which is a fairly specific 
generality. If you want to talk about a more general backtracking 
that's fine, but it won't apply to how regexes backtrack.
My impression from A5 and A6 is that rules are methods.  They're 
looked up like methods, they can be invoked like methods, etc.
They aren't methods, though. They're not code in general, they're 
regex constructions in specific. Because they live in the symbol 
table and in some cases can be invoked as subs/methods doesn't make 
them subs or methods, it makes them regex constructs with funky 
wrappers if you want to use them in a non-regex manner.

I certainly want to be able to write rules myself, manually, when I 
think it's appropriate; and use these as subrules in other methods. 
Generic backtracking semantics are needed for that, and should at 
least conceptually also apply to normal rules.
No, no it shouldn't. Rule are rules for regexes, they are *not* subs. 
If you want generic backtracking to work, then there can't be any 
difference between:

  rule foo { \w+ }

and
  sub foo { ... }
but there must be. With rules as regex constructs the semantics are 
much simpler. If we allow rules to be arbitrary code not only do we 
have to expose a fair amount of the internals of the regex engine to 
the sub so it can actually work on the stream and note its position 
(which is fine, I can do that) we also need to be able to pause foo 
in the middle and jump back in while passing in parameters of some 
sort. Neither continuations nor standard coroutines are sufficient in 
this instance, since the reinvocation must *both* preserve the state 
of the code at the time it exited but also pass in an indication as 
to what the sub should do. For example, if the foo sub was treated as 
a rule and we backtrack, should it slurp more or less?

If rules are just plain regex rules and not potentially arbitrary 
code, the required semantics are much simpler.

Then there's the issue of being able to return continuations from 
within arbitrary unnamed blocks, since the block in this:

   $foo ~~ m:w/alpha {...} number/;

should be able to participate in the backtracking activities if we're 
not drawing a distinction between rules and generic code. (Yeah, the 
syntax is wrong, but you get the point)

Ultimately the question is How do you backtrack into arbitrary code, 
and how do we know that the arbitrary code can be backtracked into? 
My answer is we don't, but I'm not sure how popular that particular 
answer is.

When common sub-patterns are inlined, simple regexen will not use 
runtime subrules at all, so

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 5:47 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
 you aren't allowed to selectively redefine
 rules in the middle of a regex that uses those rules.
This is precisely what a macro does.
Not once execution starts, no.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 5:54 PM + 3/19/03, Simon Cozens wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
 At 5:47 PM + 3/19/03, Simon Cozens wrote:
 [EMAIL PROTECTED] (Dan Sugalski) writes:
   you aren't allowed to selectively redefine
   rules in the middle of a regex that uses those rules.
 
 This is precisely what a macro does.
 Not once execution starts, no.
Compilation's just execution of a regex, albeit the Perl6::Grammar::program
regex, and that regex will need to be modified while it's in operation in
order to pick up macro is parsed definitions and apply them to the rest
of what it's parsing.
Ah, damn, I wasn't thinking far enough out. I'm not sure it'll work 
quite like that, with a single call to the regex engine that spits 
out everything in one go. More likely it'll be a set of iterative 
calls to the engine that terminate at natural sequence points, 
potentially with recursive calls into the parsing regex.

--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 8:04 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 12:35:19PM -0500, Dan Sugalski wrote:
I'll nudge Larry to add it explicitly, but in general redefinitons 
of code that you're in the middle of executing don't take effect 
immediately, and it's not really any different for regex rules than 
for subs.
Ah, but we're not redefining the sub that's running, but the subs 
it's about to call.  That works for subs, and Simon Cozens already 
pointed out we certainly also need it for rules :-)
Well, I'm not 100% sure we need it for rules. Simon's point is 
well-taken, but on further reflection what we're doing is subclassing 
the existing grammar and reinvoking the regex engine on that 
subclassed grammar, rather than redefining the grammar actually in 
use. The former doesn't require runtime redefinitions, the latter 
does, and I think we're going to use the former scheme.

Actually, we should be extraordinarily liberal with the application 
of restrictions at this phase. It's far easier to lift a 
restriction later than to impose it later,
This is perl 6, we can add a new restriction next week
We can't add them once we hit betas. I'd as soon add them now, rather 
than later.

and I very much want to stomp out any constructs that will force 
slow code execution. Yes, I may lose, but if I don't try...
You're absolutely right, and optimization is very important to me 
too.  But you can't *only* look at the speed of constructs, or we'll 
be coding in C or assembly :-)

We'll need to meet in the middle..
Well, not to be too cranky (I'm somewhat ill at the moment, so I'll 
apologize in advance) but... no. No, we don't actually have to, 
though if we could that'd be nice.

The issue of hypotheticals is complex.
Well, I'm a big boy, I'm sure I can handle it.  Are you even talking 
about semantics or implementation here?  Because I already gave my 
insights on semantics, and I have 'em in my head for implementation 
too but I should probably take those to perl6-internals instead.
Semantics. Until Larry's nailed down what he wants, there are issues 
of reestablishing hypotheticals on continuation reinvocation, 
flushing those hypotheticals multiple times, what happens to 
hypotheticals when you invoke a continuation with hypotheticals in 
effect, what happens to hypotheticals inside of coroutines when you 
establish them then yield out, and when hypotheticals are visible to 
other threads.

I read through your proposal (I'm assuming it's the one that started 
this thread) and it's not sufficient unless I missed something, which 
I may have.

Ultimately the question is How do you backtrack into arbitrary 
code, and how do we know that the arbitrary code can be backtracked 
into? My answer is we don't, but I'm not sure how popular that 
particular answer is.

I say, make generic semantics first, and then optimize the heck out of it.
That's fine. I disagree. :)
Now that Simon Cozens has established that sub-rules need to be 
looked up at runtime,
Well

Sounds like a good deal? :-)
At the moment, no. It seems like a potentially large amount of 
overhead for no particular purpose, really. I don't see any win in 
the regex case, and you're not generalizing it out to the point where 
there's a win there. (I can see where it would be useful in the 
general case, but we've come nowhere near touching that)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Rules and hypotheticals: continuations versus callbacks

[Dan Sugalski]

At 9:14 PM +0100 3/19/03, Matthijs van Duin wrote:
On Wed, Mar 19, 2003 at 02:31:58PM -0500, Dan Sugalski wrote:
Well, I'm not 100% sure we need it for rules. Simon's point is 
well-taken, but on further reflection what we're doing is 
subclassing the existing grammar and reinvoking the regex engine on 
that subclassed grammar, rather than redefining the grammar 
actually in use. The former doesn't require runtime redefinitions, 
the latter does, and I think we're going to use the former scheme.
That's not the impression I got from Simon

It would also be rather annoying.. think about balanced braces etc, 
take this rather contrieved, but valid example:

$x ~~ m X {
macro ... yada yada yada;
} X;
It seems to be that you're really inside a grammar rule when that 
macro is defined.
Right. Macro definition ends, you subclass off the parser object, 
then immediately call into it, and it eats until the end of the 
regex, at which point it exits and so does the parent, for lack of 
input, and the resulting parse tree is turned to bytecode and 
executed.

  Otherwise you'd have to keep a lot of state outside the parser to 
keep track of such things, which is exactly what perl grammars were 
supposed to avoid I think.
You, as a user-level programmer, don't have to track the state. The 
parser code will, but that's not a big deal.

We'll need to meet in the middle..
Well, not to be too cranky (I'm somewhat ill at the moment, so I'll 
apologize in advance) but... no. No, we don't actually have to, 
though if we could that'd be nice.
OK, strictly speaking that's true, but I think we can

Semantics. Until Larry's nailed down what he wants, there are issues 
of reestablishing hypotheticals on continuation reinvocation,

They should be though, if a variable was hypothesized when the 
continuation was taken, then it should be hypothesized when that 
continuation is invoked.
Should they? Does hypotheticalization count as data modification (in 
which case it shouldn't) or control modification (in which case it 
should), and do you restore the hypothetical value at the time the 
continuation was taken or just re-hypotheticalize the variables? 
(Which makes continuations potentially more expensive as you need to 
then save off more info so on invocation you can restore the 
hypothetical state)

What about co-routines, then? And does a yield from a coroutine count 
as normal or abnormal exit for pushing of hypothetical state outward, 
or doesn't it count at all?

flushing those hypotheticals multiple times,
Not idea what you mean
I hypotheticalize the variables. I then take a continuation. Flow 
continues normally, exits off the end normally, hypothetical values 
get pushed out. I invoke the continuation, flow continues, exits 
normally. Do I push the values out again?

what happens to hypotheticals when you invoke a continuation with 
hypotheticals in effect,

Basically de-hypothesize all current hypotheticals,
How? Successfully or unsuccessfully? Does it even *count* as an exit 
at all if there's a pending continuation that could potentially exit 
the hypotheticalizing block later?

what happens to hypotheticals inside of coroutines when you 
establish them then yield out,
This follows directly from the implementation of coroutines: the 
first yield is a normal return, so if you hypothesize $x before that 
it'll stay hypothesized. if you then hypothesize $y outside the 
coroutine and call the coroutine again, $y will be de-hypothesized.
Why? That doesn't make much sense, really. If a variable is 
hypotheticalized outside the coroutine when I invoke it, the 
coroutine should see the hypothetical variable. But what about yields 
from within a couroutine that's hypotheticalized a variable? That's 
neither a normal nor an abnormal return, so what happens?

If the coroutine then hypothesizes $z and yields out, $z will be 
de-hypothesized and $y
re-hypothesized.  $x will be unaffected by all this
Yech. I don't think that's the right thing to do.

and when hypotheticals are visible to other threads.
I haven't thought of that, but to be honest I'm not a big fan of 
preemptive threading anyway.
Doesn't matter whether you like it or not, they're a fact that must 
be dealt with. (And scare up a dual or better processor machine and 
I'll blow the doors off a cooperative threading scheme, 
synchronization overhead or not)

I read through your proposal (I'm assuming it's the one that started this
Sounds like a good deal? :-)
At the moment, no. It seems like a potentially large amount of 
overhead for no particular purpose, really.
I have to admit I don't know the details of how your system works, 
but what I had in mind didn't have any extra overhead at all -- 
under the (apparently still debatable) assumption that you need to 
look up subrules at runtime anyway.

You do agree that if that is possible, is *is* a good deal?
No. Honestly I still don't see the *point*, certainly not in regards 
to regular expressions

Re: XML is Too Hard for Programmers = Tim Bray

[Dan Sugalski]

At 10:54 AM -0800 3/18/03, Michael Lazzaro wrote:
A perl5-native parser can be rigged up fairly easily, but it's 
*numbingly* slow compared to the C version.  I mean, 20-50 times 
slower, by my guess.  The speed issue when importing XML-like data 
(which we do *very frequently*) is a constant sticking point for us 
and our clients.  Damian's Parse::RecDescent has been a godsend, 
implementation-wise -- but it of course suffers the same nasty speed 
issues.
I don't know that it makes a difference, as this is *really* a 
library issue rather than a language one, but there's a basic parrot 
XML parser in the parrot examples directory. It's faster (factor of 
four or so, though should speed up with our IO speedups) than the 
equivalent perl 5 version that it's a line-for-line translation of.

The performance numbers are old, it might be faster now.
--
Dan
--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A6: multi promotion

[Dan Sugalski]

At 8:16 AM -0800 3/15/03, Larry Wall wrote:
On Sat, Mar 15, 2003 at 11:27:03AM +, Nicholas Clark wrote:
: I think that it would be nice to be able to chain yourself in there, rather
: than having to replace.
:
: In perl5 there are some things you have to override, rather than adding to.
: Offhand I can't see a practical way that the opcode loop or the 
regexp engine
: could be done in any other way, but IIRC require is hookable, and
: UNIVERSAL::AUTOLOAD and the core ops have to be replaced, when 
what you might
: like to do is just wrap to extend things. Or will wrapping these routines be
: good enough?

Maybe.  For dispatch-related subs, it will depend heavily on how the
run-time system optimizes dispatches.  No way are we going through
that entire list on every dispatch without some kind of caching of
the result so that we can dispatch more directly next time.  (Perl 5
already does this with regular method dispatches.)  But if we depend
on wrapping, and if wrapping becomes a common occurrence at run time,
and if we have to recalcuate our dispatches every time someone wraps
a routine, then we're gonna be hosed on the performance front.
I hadn't actually planned on doing anything special--when you wrap a 
sub, the PMC that represents the sub gets its code pointer replaced 
with the wrapping sub PMC, which itself holds the wrapped code 
pointer. Wrap something and generally nobody knows the difference, 
because the outside interface and address doesn't change.

Unwrapping puts the pointer back again and removes the under-the-hood 
messing about, once again transparently.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A6: Signature zones and such

[Dan Sugalski]

At 3:07 PM + 3/14/03, Piers Cawley wrote:
Brad Hughes [EMAIL PROTECTED] writes:

 Piers Cawley wrote:
 [...]
 Nope, send it to TPF as discussed. It's what I've said in all the
 summaries after all. I just hope that a chunk of it ends up in Larry's
 pocket.
 Does anyone know if TPF is set up to allow earmarked contributions?
Dunno. But I'm merely expressing a preference. TPF can do with it what
they will.
Earmarked contributions are apparently somewhat dodgy from an IRS 
perspective--they don't want folks setting up a 503(c)(3) to do 
payroll stuff as a way to avoid taxes. (Rather than have an employee 
you have a grantee of a charity, thus the money you use to pay that 
person becomes a tax deduction, or something like that)

The TPF's grant fund stuff's OK, though. It's just a matter of 
getting a grantee for this year... (Working on that)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: A6: Signature zones and such

[Dan Sugalski]

At 8:07 AM -0800 3/14/03, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
 At 3:07 PM + 3/14/03, Piers Cawley wrote:
 Brad Hughes [EMAIL PROTECTED] writes:
 
   Piers Cawley wrote:
   [...]
   Nope, send it to TPF as discussed. It's what I've said in all
 the
   summaries after all. I just hope that a chunk of it ends up in
 Larry's
   pocket.
 
   Does anyone know if TPF is set up to allow earmarked
 contributions?
 
 Dunno. But I'm merely expressing a preference. TPF can do with it
 what
 they will.
 Earmarked contributions are apparently somewhat dodgy from an IRS
 perspective--they don't want folks setting up a 503(c)(3) to do
 payroll stuff as a way to avoid taxes. (Rather than have an employee
 you have a grantee of a charity, thus the money you use to pay that
 person becomes a tax deduction, or something like that)
 The TPF's grant fund stuff's OK, though. It's just a matter of
 getting a grantee for this year... (Working on that)
This doesn't seem right. The United Way runs directed drives all the
time, in which they raise money for a particular cause. (And tap me on
the shoulder...)
There's no reason the TPF couldn't run a Fund P6 drive.
There's a difference between Fund project X and Fund person X. 
Funding a project, and having one person suitable to do the project, 
is OK, generally speaking. (Though I expect the feds still peer 
pretty closely) Funding a specific person is dodgier.

That means that TPF's perl development grant fund is fine to donate 
to, and if there's only enough cash for one grantee, and Larry's the 
best candidate, that's keen. Setting up a Fund Larry Wall fund is 
where things get much less easy.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: signal/slot like mechanism

[Dan Sugalski]

At 6:27 PM + 3/6/03, Yannick Le Saint wrote:
  Hi guys, i was just wondering if some notification mechanism ( signal/slot
alike ) was planned in perl 6, like they already are in glib and qt ?
I'm not exactly sure what you're looking for, since I'm not too 
familiar with qt or glib, but if you mean will there be a mechanism 
to register watcher subs that get called when things happen 
internally (such as when a method is defined or redefined, or a class 
changes, or something of the sort) then yes, we'll be doing that.

It solves a fairly thorny problem with making efficient specific 
solutions in the face of a general problem, so there'll be built-in 
facilities for it. (What it means for parrot, specifically, is that 
we can build call structures and code designed specifically for 
whatever is the current set of methods and class behaviours, knowing 
that if something changes we can just rebuild our stuff based on the 
new layout because we've got a notification method registered)
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Multiple Inheritance eq Interfaces [was: Re: Object spec]

[Dan Sugalski]

At 5:02 AM +1300 3/6/03, Sam Vilain wrote:
No.  All I'm saying is that this sort of construct:

   *{$_} = \{Class::$_} foreach (qw(method method2 method3));

Gives you everything that inheriting a class does, apart from the -isa()
relationship.  And potential unwanted namespace pollution.
It's probably time to note that, when I started the discussion, it 
was on perl6-internals, and all I was interested in was nailing down 
needed semantics. What you've started talking about is perl 6 
*language* syntax and such. I'm not sure Larry's ready to start that 
yet.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

RE: Object spec

[Dan Sugalski]

At 10:10 AM -0600 3/5/03, Garrett Goebel wrote:
Several people have mentioned a desire to see Perl6 and Parrot facilitate
object persistence. Should such issues be tackled in Parrot?
To some extent, yes. (And as such this is CC'd to both p6l and p6i, 
but discussion really belongs in p6i)

There's a freeze and thaw vtable entry for PMCs, and I've got 
sketches of necessary core functionality to make it fesable. At some 
point I'll get it down in electrons and fire it to p6i for hashing 
out. Basically we delegate to the PMC's code and let it do what it 
needs to. Standard serializers will be provided for mostly-passive 
variables, which should cover most common cases, while still allowing 
escapes for funkier (serializing file handles, sockets, or DB 
connections) cases.
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Arrays: Default Values

[Dan Sugalski]

At 9:53 AM -0800 1/30/03, Michael Lazzaro wrote:

This is leading me to the conclusion that primitive-typed arrays 
should not be allowed to have defaults, period, and that attempting 
to place one should be a compile-time error.  If you want a default, 
use CInt instead of an Cint, and it will work fine.

This isn't necessarily an issue for low-level arrays/hashes. We've 
got to fill the new elements with something when we extend internal 
structures, so there's no reason not to set the default. Doesn't mean 
the default should be a value that can fall outside the range that's 
OK for the low-level type, but...
--
Dan

--it's like this---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk