Re: Auto My?

[JOSEPH RYAN]

- Original Message -
From: Luke Palmer <[EMAIL PROTECTED]>
Date: Saturday, December 18, 2004 4:16 pm
Subject: Re: Auto My?

> Rod Adams writes:
> There are pros and cons, and it basically ends up being a design 
> choice.
> > Well, at least when strictures are on. When they are off, the 
> coder is 
> > obviously playing fast and loose, and should get the easy 
> 'everything 
> > global' behavior.
> 
> When strictures are on, the compiler ought to die if you're tyring to
> use a variable without declaration.  This is another reason why Perl
> doesn't like autodeclaration.

As bad of an idea that I think this is, I wonder if 
Perl6's reflection capabilities will be powerful 
enough to where a module/pragma could be written 
that would be able to do this?  For instance, one 
idea was: lexically change the current grammar to a 
subclass of the grammar.  In this subclass, there is
a hook on the "variable" deparsing rule that will 
implictly declare a variable into its outer scope if
it has not yet been declared in the current scope.  
Totally whacky, sure; but doable?

That brings up another idea that I had just now: 
will it be possible to load 2 different grammars at
once if they don't conflict with each other?  For 
instance, say we have loaded a grammer, 
Grammar::WhackyVars, that subclasses from the main 
Perl6 grammar but modifies the "variable" rule 
somehow.  However, then say I want to use a grammar
that also subclasses from the main Perl6 grammar 
that lets you use "happyfunactiontime" instead of 
the word "class".  Since the modified rules don't 
conflict with each other, can I just "use 
Grammar::HappyFunActionTime" and everything will 
work?  Or will Grammar::HappyFunActionTime overload
the changes done by the Grammar::WhackyVars?

- Joe

Re: Still about subroutines...

[JOSEPH RYAN]

- Original Message -
From: Juerd <[EMAIL PROTECTED]>
Date: Thursday, September 16, 2004 2:55 pm
Subject: Re: Still about subroutines...

> Jonathan Scott Duff skribis 2004-09-16 13:44 (-0500):
> > Speaking of which ... why is it that $?foo and  became 
> $<>> and <> respectively?  
> 
> perlcheat is one page. I hope that when Perl 6 is around, I can
> summarize all uses of << and >> on one page. The second page will 
> be for
> the rest of the syntax :)

Don't forget to leave a whole page each for * and : too. :)

- Joe

Re: Current state?

[JOSEPH RYAN]

- Original Message -
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Tuesday, September 14, 2004 3:56 pm
Subject: Re: Current state?

> On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote:
> > : Of course, this is really language design -- Larry, you listening?
> > 
> > Sure, I'm listening, but what's the point when I agree with 
> everyone.  :-)
> > 
> > I agree that the default should be the current outer language.
> > I agree that the default ought to be overridable.
> > I agree that the right way to do that is with something like 
> "use PIR;"
> > rather than inventing an inconsistent syntax.
> 
> This will likely betray some deep ignorance on my part (and this
> discussion may have taken place already elsewhere), but since I'm 
> currently working on a rules syntax parser I'll barrel forth 
> anyway:  
> 
> What should the mechanism be for the rule parser to figure out 
> where 
> a closure begins and ends within a rule expression?  Does the rules
> parser have to call the outer language compiler directly?  

Since a closure can contain arbitrary Perl6 code, yeah.  But I was under the 
impression that parsing the rules themselves needed to be done by the outer language 
parser just because of that jazz.  Maybe the outer language parser could parse the 
rule first, and then replace language-specific constructs with stubs or the body of a 
PIR sub:

rule rules {
$rules := (rules) { for 1..5 { print "$rules totally rule.\n" } }
}

And, after the outer language Perl6 compiler gets done with it, the Rules Engine would 
see:

rule rules {
(rules) {
.param MatchObject match

set $I1, 1
new $P0, .PerlString
set $P0, " totally rule."
L_1:

new $P1, .PerlString
clone $P1, match["1"]
concat $P1, $P0
print $P1
inc $I1
le $I1, 5, L_I
}
}

And then it would be easy to find the end of the closure construct since it will 
contain plain ol' PIR.

> If so, does this imply that the rules parser has to be running in 
> Parrot to be able to call the outer language compiler, or is there 
> a 
> way to do this from C?
> 
> And does the outer language compiler have to have options that
> allow the caller to say: "hey, here's some program code with 
> perhaps 
> a bunch of rule-syntax stuff appended to it, could you just give 
> me 
> back the first complete 'closure unit' and oh, by the way, tell me 
> how 
> many characters you used to do it or give me the left-over string so
> I can continue parsing my stuff?"

Well, you could always design the compiler so that it can be put into a special mode 
that:

- recieves the raw text as an argument
- tries to parse a whole block from that (e.g., starts at rule "block" instead of rule 
"prog")
- if successful, compiles that block into a closure PMC and modifies the raw text by 
deleting the parsed text from the start of it.  (kinda like 
Parse::RecDescent::Consumer)
- returns the closure PMC and the modified text

> Or is there some syntactic shortcut that can be made to let us find
> the end of a closure without having to fully parse the closure itself?
> 
> How does p5 do it?

p5 just tries to find a balanced set of curlies.

> (And you can see why I've been willing to postpone true closures 
> in 
> rules just a bit longer until we got a p6 compiler started. :-)

Oh, definitely, definitely. :)

- Joe

Re: Current state?

[JOSEPH RYAN]

- Original Message -
From: Jared Rhine <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 5:22 pm
Subject: Current state?

> [Patrick == [EMAIL PROTECTED] on Wed, 8 Sep 2004 11:51:18 -0600]
> 
>  Patrick> ...in the immediate future we'll be wanting rules/grammar
>  Patrick> tests (to test the grammar engine) more than we'll need
>  Patrick> perl 6 code, although we'll certainly take that as well.
> 
> If you wanted to describe the form such tests might take, maybe
> Herbert will get excited enough to pitch in with such tests.  I grok
> the difference between the grammar engine and the actual compiler, but
> I'm blanking on how to describe the process of writing tests that
> aren't simple "Perl 6 code snippet" style tests at this early stage.

Test::More with Parrot::Test would probably be good enough.  For an example, take a 
look at:

http://xrl.us/cy66

Except that in this case, it would just be something like:

##
# to test $0
output_is(<<'CODE', <<'OUT', "Description.");
"a string on which to test the pattern" =~ /(pattern)/
CODE
pattern
OUT

- Joe

Re: multiple languages clarification - newbie

[JOSEPH RYAN]

- Original Message -
From: JOSEPH RYAN <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 8:58 pm
Subject: Re: multiple languages clarification - newbie

>macro prolog is parsed(/
>   \: ([
> <[^p]>+ ::
>   |  p 
>   ]+)
>/) {
>eval($_, "prolog");
>}

Woops, actually, that would need to be:

macro prolog is parsed(m:w/
   \: ([
 <[^p]>+ ::
   |  p 
   ]+)
   prolog \. ;
/) {
eval($_, "prolog");
}

But, this is perl6-language stuff anyways. (:

- Joe

Re: Current state?

[JOSEPH RYAN]

- Original Message -
From: Larry Wall <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 3:09 pm
Subject: Re: Current state?

> On Wed, Sep 08, 2004 at 02:47:24PM -0400, JOSEPH RYAN wrote:
> : We tried that as an optimization in the prototype 
> : Perl6 compiler.  It ended up being a really really 
> : really bad idea because the grammar backtracked like 
> : a madman.  It might be workable if we can infuse 
> : 's in every location possible...
> 
> I presume you mean the lower-level backtracking controls.  A 
> can only cause you to fail completely, and then only if you backtrack
> over it.  (Or are you referring specifically to efficient error
> recovery?)

Well, I meant in the sense of "Ok, since we're 
ing here, we should assume that everything 
we've already parsed is ok (i.e., we're not going to 
backtrack over it).  Its now ok to translate it into
PIR without wasting our time."  The idea was to 
reduce/eliminate the translation of code that might
get backtracked over.

- Joe

Re: multiple languages clarification - newbie

[JOSEPH RYAN]

- Original Message -
From: mAsterdam <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 8:31 pm
Subject: Re: multiple languages clarification - newbie

> Joseph Ryan wrote:
> 
> >>Can someone provide clarification on what mixing languages will 
> >>look like in practice, or point me to where its explained?
> 
>  Warning. This is perl 7 and a half:
> 
> #!/usr/bin/perl -w
> use prolog;
> 
> prolog:   # prolog tells us:
> 
> needs_support_of(Db, Da):-
> designer(A, Da),
> designer(B, Db),
> needs(A, B).
> 
> designer(perl, larry).
> designer(parrot, dan).
> needs(perl, parrot).
> 
> prolog. ;# or some other end-quote
> 
> for needs_support_of {
> print;   # prints 1st in the signature of the unification,
>  # predicate, 2nd .. nth in the signature of the
>  # match (for one member of the result).
> }
> 
> __END__
> 
> 

You could do that in Perl6 (or any Parrot based language) as:

eval "
needs_support_of(Db, Da):-
designer(A, Da),
designer(B, Db),
needs(A, B).

designer(perl, larry).
designer(parrot, dan).
needs(perl, parrot).
", "prolog";

for needs_support_of() {
print;   # prints 1st in the signature of the unification,
 # predicate, 2nd .. nth in the signature of the
 # match (for one member of the result).
}

Assuming, of course, that there exists a prolog->parrot compiler.

You could even have your syntax if you use a macro:

macro prolog is parsed(/
   \: ([
 <[^p]>+ ::
   |  p 
   ]+)
/) {
eval($_, "prolog");
}

- Joe

Re: multiple languages clarification - newbie

[JOSEPH RYAN]

- Original Message -
From: Richard Jolly <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 6:02 pm
Subject: multiple languages clarification - newbie

> Hi,
> 
> 
> 
> Can someone provide clarification on what mixing languages will 
> look 
> like in practice, or point me to where its explained?

I think you mean mixed language libraries/modules 
rather than mixed languages (to mix languages, you'd
need to do a multi-arg eval like in Dan's example).
Using another language's module, however, would not
pay attention to the other language's syntax at all.
You would C the module in your code, and 
then interface with it just as if it were written in
the language that you were writing in (and not in the
language that the module was written in).

So this:

> #!/usr/bin/perl6
> 
> use __Python::sys;# whatever syntax
> sys.stdout.write( 'hi there');# perl6 syntax matches python 
> syntax 
> here, I think

would become this: (Apologies, I don't know Python, 
well, at all, so I'll state what assumptions I make) 

#!/usr/bin/perl6
use __Python::sys;

# I'm assuming that C<$stdout> is some sort of
# global object in the C namespace.
$*sys::stdout.write('hi there');

> And this:
> 
> #!/usr/bin/ponie
> 
> use __Python::sys;
> use __Python::string;
> 
> my $hi = __Python::string->upper( 'hi' )
> sys->stdout->write( $hi );   # HI
> 
> 
> my $upper_func = __Python::string->upper # does this call the
>  # function with no args 
> (perlish)
>  # or return it (pythonish)

#!/usr/bin/ponie
use __Python::sys;
use __Python::string;

use UNIVERSAL qw(can);

# here I'm assuming that C<$string> is a global
# object in the C<__Python> namespace.
my $hi = $__Python::string->upper('hi')  # Hi;
my $hi_func1 = \&__Python::string::upper;
my $hi_func2 = can($__Python::string,'upper');

The idea is that after compilition, everything is 
just PMCs and PIR, and so everything (hopefully) 
plays nice together.

- Joe

Re: Current state?

[JOSEPH RYAN]

- Original Message -
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 1:21 pm
Subject: Re: Current state?

> On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
> > On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud wrote:
> > : We're in the beginning stages of building a basic perl 6 
> grammar engine 
> > : (i.e., probably without p6 closures) that compiles to parrot 
> and handles
> > : basic optimizations.
> > 
> > I wonder whether, in the absence of closures, we'll have to have 
> some> similar way to embed syntax-tree building code (PIR?) as 
> actions in
> > the grammar.  
> 
> We may indeed need this.  I think the easiest way would be to
> build some sort of "special-purpose" assertions or rules that
> fire off some PIR code.  

That's probably the best solution for now.

> Or, perhaps we can just find a way to do a funky sort of replacement
> whereby p6 source code gets replaced by its equivalent PIR code as
> soon as the compiler think it has a rule matched.  Naaah, scratch 
> that.

We tried that as an optimization in the prototype 
Perl6 compiler.  It ended up being a really really 
really bad idea because the grammar backtracked like 
a madman.  It might be workable if we can infuse 
's in every location possible...

- Joe

Re: Current state?

[JOSEPH RYAN]

- Original Message -
From: Dan Sugalski <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 1:56 pm
Subject: Re: Current state?

> At 11:21 AM -0600 9/8/04, Patrick R. Michaud wrote:
> >On Wed, Sep 08, 2004 at 09:56:12AM -0700, Larry Wall wrote:
> >>  On Wed, Sep 08, 2004 at 07:33:45AM -0600, Patrick R. Michaud 
> wrote:>>  : We're in the beginning stages of building a basic perl 
> 6 grammar engine
> >>  : (i.e., probably without p6 closures) that compiles to parrot 
> and handles
> >>  : basic optimizations.
> >>
> >>  I wonder whether, in the absence of closures, we'll have to 
> have some
> >>  similar way to embed syntax-tree building code (PIR?) as 
> actions in
> >>  the grammar. 
> >
> >We may indeed need this.
> 
> Or we could just get closures working...

To get closure assertions working, you need  
something that compiles the code in the
closure assertion, and so there is a bit of a 
bootstrapping problem. (:

Maybe some sort of compromise/hack solution would 
work, where closure assertions would be allowed but 
only contain simple assignments: 

  rule hack {
(\d)(<[a-z]>)\2
<{ $0 = $1 }>
  }

Re: Current state?

[JOSEPH RYAN]

- Original Message -
From: Jared Rhine <[EMAIL PROTECTED]>
Date: Wednesday, September 8, 2004 12:19 pm
Subject: Current state?

> [Herbert == [EMAIL PROTECTED] on Wed, 8 Sep 2004 15:18:27 +]
> 
>  Herbert> And any way for an overeager newbie to help?
> 
> The classic answer is "write tests".  There's thousands of code
> snippets that have been tossed out to the various perl6-* lists over
> the last few years.

If you want to write tests, I would say the best place to start is the A5 stuff, for 
two reasons:

a.) Grammar/Regex tests would be really useful in testing the Grammar engine.

b.) The A5 stuff is definitely the most stable part of the Perl6 design.  As far as I 
know, it hasn't really changed much at all over the past 2 years.  You could probably 
work directly off of A5 and S5 without having to worry if the reality is much 
different from the document.

- Joe

Re: Why do users need FileHandles?

[JOSEPH RYAN]

I define "outside the core" as "anything that isn't
packaged with Perl itself".  Things you'd define as
"part of the language."  I/O stuff, threading stuff,
standard types, builtin functions, etc.  And yeah,
most of that stuff will be written natively in C, 
PIR, or be part of parrot itself.

I think there will also be a much larger "standard 
library" that will be bundled separately, which would
contain your libwww, libnet, and other 
widely/commonly used modules.  The way I think of it
is kinda like installing something with the windows
installer: you can check to install the "minimal" or 
standard version, the "full" version (which would be
perl + the "standard library"), or you could even 
check "custom" and choose what you'd like to
install.  And, of course, everything else
would just be on the CPAN.

- Joe

Re: Why do users need FileHandles?

[JOSEPH RYAN]

- Original Message -
From: Dan Hursh <[EMAIL PROTECTED]>
Date: Thursday, July 22, 2004 3:07 pm
Subject: Re: Why do users need FileHandles?

> Luke Palmer wrote:
> 
> > JOSEPH RYAN writes:
> > 
> >>- Original Message -
> >>From: David Storrs <[EMAIL PROTECTED]>
> >>Date: Monday, July 19, 2004 5:04 pm
> >>Subject: Re: Why do users need FileHandles?
> >>
> >>
> >>>Second, I would suggest that it NOT go in a library...this is
> >>>reasonably serious under-the-hood magic and should be 
> integrated into
> >>>the core for efficiency.
> >>
> >>How would integrating this in the core make it more efficient?  Core
> >>or not, I'd see something like this being implemented with a custom
> >>pmc.  I tend to think of inclusion in the core being more of a
> >>philosophical decision...
> > 
> > 
> > Yes, it is.  Whether or not a PMC is in the core, it should be 
> equally> fast.  That is, unless Parrot is allowed intimate 
> knowledge of the PMC's
> > internals.  And there are very few (any?) PMCs that possess this
> > property even now.
> > 
> > Even more philosophical is "what is core?"  I get the impression 
> that> Larry is trying to blur the distinction between core and non-
> core as
> > much as possible.  So making it "go in the core" may just mean 
> that it's
> > on the list of recommended modules to install.
> > 
> > Luke
> 
> How about we say "in core" means it packaged with the perl6 source 
> and 
> covered in the coresponding camel & lama books.  :)

Well, that's what all of the ruckus is about. 
There is a strong leaning towards including *no* 
builtin modules with the core.  So, that leaves only
the builtin functions and classes as "the core", and 
so what is "in core" becomes a pretty big deal.

- Joe

Re: xx and re-running

[JOSEPH RYAN]

- Original Message -
From: James Mastros <[EMAIL PROTECTED]>
Date: Sunday, July 18, 2004 5:03 am
Subject: xx and re-running

> Recently on perlmonks, at 
> http://perlmonks.org/index.pl?node_id=375255, 
> someone (DWS, actually) brought up the common error of expecting x 
> (in 
> particular, listy x, which is xx in perl6) to not create aliases.  
> What 
> he was doing in particular, I don't have any expectation of making 
> it 
> work, but what about the also-common problem of C< @randoms = (int 
> rand 
> 100) xx 100 >?  In perl5, this picks one random integer between 0 
> and 
> 99, and copies it 100 times -- not what was intended.  The best 
> way to 
> do this is C< my @randoms = map {int rand 100} 0..100; >, which is 
> rather yucky -- conceptually, you aren't trying to transform one 
> list 
> into another.  OTOH, C< my @randoms; push @randoms, int rand 100 
> for 
> 0..100 > is even yuckier.
> 
> Perhaps if the LHS of a xx operator is a closure, it should run 
> the 
> closure each time around... or perhaps there should be an xxx 
> operator. 
>  (Both suggestions from BrowserUk's reply, 
> http://perlmonks.org/index.pl?node_id=375344).  The former raises 
> the 
> question of what you do if you really want to repeat a coderef, 
> and the 
> later raises the possibly of being blocked (really), and starts to 
> become confusing -- the difference between x and xx is sensical -- 
> the 
> former repeats one thing, the later many... but what's the 
> reasoning for 
> xxx, other then that it's like xx?  How will users be able to 
> remember 
> which is which?=

When I think about your description of xxx, I 
summarized it in my head as "Call a coderef a certain
number of times, and then collect the results."  
That's pretty much what map is, except that xxx is 
infix and map is prefix.


@results = { ... } xxx 100;
@results = map { ... } 1.. 100;

Doesn't seem that special to me.

- Joe

Re: Why do users need FileHandles?

[JOSEPH RYAN]

- Original Message -
From: Luke Palmer <[EMAIL PROTECTED]>
Date: Thursday, July 22, 2004 2:48 pm
Subject: Re: Why do users need FileHandles?

>> JOSEPH RYAN writes:
> > 
> > How would integrating this in the core make it more efficient?  Core
> > or not, I'd see something like this being implemented with a custom
> > pmc.  I tend to think of inclusion in the core being more of a
> > philosophical decision...
> 
> Yes, it is.  Whether or not a PMC is in the core, it should be equally
> fast.  That is, unless Parrot is allowed intimate knowledge of the 
> PMC'sinternals.  And there are very few (any?) PMCs that possess this
> property even now.

But why would Parrot need to see the PMC's internals?  I was thinking more along the 
lines of a class just looked just like PerlString, except with different, uh, stuff in 
the pmc class methods.

> Even more philosophical is "what is core?"  I get the impression that
> Larry is trying to blur the distinction between core and non-core as
> much as possible.  So making it "go in the core" may just mean 
> that it's
> on the list of recommended modules to install.

You're probably right.  Every time I think about the idea of "there will be no core 
modules", a conservative part of me becomes scared out of its mind, and that 
conservative side wants to riot.  But, once I think about it a little more, that riot 
quickly gets beaten down with thought batons like: "Sure, there won't be any core 
modules, but most of what Perl5's core will be seamlessly built into the language 
anyways, and not having other core modules will free everyone from having to continue 
to use crusty old interfaces like Exporter and File::Find".

But, going back to the original topic, something like this kind of I/O abstraction 
should still be some sort of *module* (core or not), not a core *behaivor*.

Re: Why do users need FileHandles?

[JOSEPH RYAN]

- Original Message -
From: David Storrs <[EMAIL PROTECTED]>
Date: Monday, July 19, 2004 5:04 pm
Subject: Re: Why do users need FileHandles?

> Second, I would suggest that it NOT go in a library...this is
> reasonably serious under-the-hood magic and should be integrated into
> the core for efficiency.

How would integrating this in the core make it more efficient?  Core or not, I'd see 
something like this being implemented with a custom pmc.  I tend to think of inclusion 
in the core being more of a philosophical decision...

- Joe

Re: push with lazy lists

[JOSEPH RYAN]

> On Wed, Jul 07, 2004 at 11:50:16PM -0400, JOSEPH RYAN wrote:
>
> To answer the latter first, rand (with no arguments) returns a number
> greater than or equal to 0 and less than 1 which when used as an index
> into an array gets turned into a 0.
> 
> As to why the second pop would take forever, I'd imagine that in order
> to pop the last item from the array, all of the elements must 
> first be
> generated (i.e. we lose all laziness). And unless we have some 
> magic for
> generating them from either end, it'll start at the begining and
> continue until the end, then stop before it ever does the pop. :-)

Ah, right, I should known that, in both cases. (:  Thanks for answering my silly 
questions.

- Joe

Re: push with lazy lists

[JOSEPH RYAN]

- Original Message -
From: Larry Wall <[EMAIL PROTECTED]>
Date: Wednesday, July 7, 2004 11:25 pm
Subject: Re: push with lazy lists

> On Fri, Jul 02, 2004 at 09:32:07PM -0500, Dan
Hursh wrote:
> : how 'bout
> : 
> : @x = gather{
> : loop{
> : take time
> : }
> : }   # can this be @x = gather { take time loop }
> : push @x, "later";
> : say pop @x;# "later"
> 
> Can probably be made to work right.
> 
> : say pop @x;# heat death?
> 
> Yes.
> 
> : say @x[rand];  # how about now?
> 
> Well, that's always going to ask for @x[0], which
isn't a problem.
> However, if you say rand(@x), it has to calculate
the number of
> elements in @x, which could take a little while...

Why would the second pop be a heat death, and why
would rand always return 0?

- Joe

Re: push with lazy lists

[JOSEPH RYAN]

- Original Message -
From: Dan Hursh <[EMAIL PROTECTED]>
Date: Friday, July 2, 2004 10:32 pm
Subject: Re: push with lazy lists

>> Joseph Ryan wrote:
> I guess that's true with X..Y lazy lists.  I
thought there were 
> other 
> ways to make lazy lists, like giving it a closure
that gets called 
> lazily to populate the list with the result's
being cached.  I 
> can't 
> remember the syntax though.  I think gather was
one way.  Maybe 
> I'm just 
> remembering wrong.
> 
> Anyhow, I was thiking that was how X..Inf was
implemented.  That 
> would 
> be foolish in this case.
> 
> how 'bout
> 
> @x = gather{
> loop{
> take time
> }
> }   # can this be @x = gather { take time loop }
> push @x, "later";
> say pop @x;# "later"
> say pop @x;# heat death?
> say @x[rand];  # how about now?

I'm a bit confused by your syntax, but I think I 
understand what you mean.  I was under the impression
that loops were not lazily evaluated, but essentially
run until they were broken out of.  The advantage of
using an infinite list is just that you have an 
iterator that never runs out.

> > Also, any list that contains and infinite list
becomes tied.  
> The container list's FETCH would change so that
any accessed index 
> that falls within the indexes "owned" by the
infinite list would 
> be dispatched to the infinite list.  So, with a
list like:
> > 
> > @array = ('a','b','c',2..Inf,"woops");
> > 
> > Elements 0, 1, and 2 would be accessable as
normal, but then 
> elements 3 through Inf would be dispatched to the
infinite list.  
> However, since "woops"'s index is also Inf, and
that index is 
> "owned" by the infinite list, it would be
impossible to access it 
> except through a pop call (which doesn't look at
indexes at all).
> 
> I was wondering about lazy list where we don't
know how many 
> element it 
> might generate.  Admittedly, I picked a poor
example.  I would 
> right to 
> assume woops would also be accessable with
@array[-1], right?

Oh yeah, that would work too. :)

- Joe

Re: push with lazy lists

[JOSEPH RYAN]

- Original Message -
From: Dan Hursh <[EMAIL PROTECTED]>
Date: Friday, July 2, 2004 2:23 pm
Subject: push with lazy lists

> Hi,
> 
> If I can assume:
> 
>   @x = 3..5;
>   say pop @x;# prints 5
>   
>   @x = 3..5;
>   push @x, 6;
>   say pop @x;# prints 6
>   say pop @x;# prints 5
> 
> What should I expect for the following?
> 
>   @x = 3..Inf;
>   say pop @x;# heat death?
>   
>   @x = 3..Inf;
>   push @x, 6;# heat death or
># an array with infinity + 1 elements?
>   say pop @x;# prints 6?
>   say pop @x;# heat death?

The way I understand the magicness of lazy lists, I'd expect:

@x = 3..Inf;
say pop @x; # prints Inf

@x = 3..Inf;
push @x, 6; # an array with the first part being 
# lazy, and then the element 6

say pop @x; # prints 6
say pop @x; # prints Inf
say pop @x; # prints Inf
say pop @x; # prints Inf

# etc 

The way I think of a lazy infinite list is kind of like a special object.  It needs to 
keep track of what the start is and what the end is.  Every other element doesn't 
actually exist, but is calculated based on the index of the 
FETCH/STORE/SPLICE/whatever call.

Also, any list that contains and infinite list becomes tied.  The container list's 
FETCH would change so that any accessed index that falls within the indexes "owned" by 
the infinite list would be dispatched to the infinite list.  So, with a list like:

@array = ('a','b','c',2..Inf,"woops");

Elements 0, 1, and 2 would be accessable as normal, but then elements 3 through Inf 
would be dispatched to the infinite list.  However, since "woops"'s index is also Inf, 
and that index is "owned" by the infinite list, it would be impossible to access it 
except through a pop call (which doesn't look at indexes at all).

Actually, I think that this logic could apply to any array/list constructed with .. or 
..., and an infinite list would just be a special case of that.  It would definitely 
be useful in cases like: @array = 1..20;

- Joe

Re: if not C<,> then what?

[JOSEPH RYAN]

- Original Message -
From: David Storrs <[EMAIL PROTECTED]>
Date: Thursday, July 1, 2004 7:55 pm
Subject: Re: if not C<,> then what?

> On Thu, Jul 01, 2004 at 04:14:37PM -0700, Jonathan Lang wrote:
> > Juerd wrote:
> > 
> > If you're really enamoured with the infix operator syntax, 
> consider this
> > possibility: 
> > 
> >   sub infix:-> ($before, $after) {
> > $before;   # is this line redundant?  
> > return $after;
> >   }
> >   print $a -> $b -> $c;   # prints $c
> > 
> > where C[->] is read as "followed by".  You could even set up a
> > right-to-left version, C[<-], but why bother?  
> 
> You could do this, but you'd be overriding the current meaning of 
> C<< -> >> as "pointy sub".
> 
> You could also use, 'before':
> 
>#  Recipe for (un)holy water that will irk the altar's god.
>step_on_altar();
>drop_water($_) before pray() for @water_potions;
> 
> OOC, can you define an operator that is made up of alphanumerics, or
> only punctuation?  e.g., is this legal?
> 
> sub infix:before ( $before, $after ){ ... }
> 
> --Dks

Sure.  The parser won't care what kind of characters
make up the operator, as long as its defined by the
time the operator is encountered.  The "operator" 
rules in the grammar will probably be as simple as this:

# where x is the type of operator; infix, prefix, etc
rule x_operator:u2 {
%*X_OPERATORS
}

- Joe

Re: undo()?

[JOSEPH RYAN]

- Original Message -
From: Luke Palmer <[EMAIL PROTECTED]>
Date: Tuesday, June 29, 2004 7:31 pm
Subject: Re: undo()?
> 
> Oh no!  Someone doesn't understand continuations!  How could this
> happen?!  :-)
> 
> You need two things to bring the state of the process back to an 
> earlierstate: undo and continuations.  People say continuations 
> are like time
> traveling; I like to put it this way:
> 
> Say you're in the kitchen in front of the refrigerator, thinking 
> about a
> sandwitch.  You take a continuation right there and stick it in your
> pocket.  Then you get some turkey and bread out of the 
> refrigerator and
> make yourself a sandwitch, which is now sitting on the counter.  You
> invoke the continuation in your pocket, and you find yourself standing
> in front of the refrigerator again, thinking about a sandwitch.  But
> fortunately, there's a sandwitch on the counter, and all the materials
> used to make it are gone.  So you eat it. :-)
> 
> A continuation doesn't save data.  It's just a closure that closes 
> overthe execution stack (and any lexicals associated with it; thus 
> the "I
> want a sandwitch" thought).  If things change between the taking and
> invoking of the continuation, those things remain changed after
> invoking.
> 
> > You could make the programmer specify which variables he wants delta
> > data for, and then any *others* wouldn't keep it and wouldn't be
> > undoable.
> > 
> > use undo <>; # Or use the funny characters I can't 
> type.> my $foo++;  $foo.undo();  # Undoes the increment.
> > my $quux++; $quux.undo(); # Throws an exception or something.
> 
> A much more useful way to do this would be:
> 
>use undo << $foo $bar $baz >>;
>my $foo = 41;
>my $state = undo.save;
>$foo++;  $foo.undo($state);  # or perhaps $state.remember;

Do you think it would be possible to implement C with pure Perl6 using 
continuations?  My intuition thinks it could, but my brain starts hating me when I 
start to think about it... It would definitely be a pretty neat module if it could be 
done though.

P.S. That was a truly spectacular explanation of continuations. :)

Re: A stack for Perl?

[JOSEPH RYAN]

- Original Message -
From: Luke Palmer <[EMAIL PROTECTED]>
Date: Tuesday, June 29, 2004 6:13 am
Subject: Re: A stack for Perl?

> >   1;
> >   $_='foo bar baz';
> >   split;
> >   # @STACK now is (1, 'foo', 'bar', 'baz');
> > 
> To boot, I can't think of a way to implement that in currently-defined
> Perl 6, which should scare you.

I think it could be implemented by proxying the base Perl PMCs (or, alternatively, 
tying each class for each of the base types, or whatever). Then, in each FETCH 
equivalant, wanted() could be checked to see if the FETCHish call was made in void 
context. If so, the object could push itself onto @*STACK.  So, I think it could be 
implemented in a module, which is probably a good thing, because seeing something like 
this in standard code would just be annoying.

(Although, now that I think about it, @*STACK seems to just be the inverse of 
$_/@_/%_, so maybe @*STACK should be named @¯ :)

Re: P6C: Parser Weirdness

[Joseph Ryan]

Steve Fink wrote:
Neither of those seems right to me. The first keys off of the position
of the binary, which could be anywhere with respect to the library
module you're in; the second is relative to whatever the current
directory is while you're running the script. I would think that
something like
 use File::Basename qw(dirname);
 use lib dirname($INC{"P6C/Parser.pm"})."/../../../../lib";
(untested and probably not quite the right path) would be better. Or
perhaps it should be ripped out entirely, and any script using
P6C::Parser should be required to set the lib path correctly? It
partly depends on whether we want to ensure that P6C::Parser
preferentially uses the Parse::RecDescent from parrot/lib rather than
a system-provided one. Which probably is not the case?
The Parse::RecDescent in parrot/lib is a hacked version that removes
a bunch of stuff (tracing code, iirc) from the outputted grammer so
that it runs many orders faster than the regular version.  Or, to
put it another way, it increases P6C's runspeed from "infuriating"
to "slow" :)
- Joe

Re: Ladies and gentlemen, I give you... objects!

[Joseph Ryan]

Larry Wall wrote:

On Fri, Feb 27, 2004 at 09:08:31AM -0500, Dan Sugalski wrote:
: Nope. If a language wants to provide get/set methods for class 
: attributes it needs to create those methods at compilation time.

For Perl 6 it's a single method that might be lvaluable depending on
the declaration of the attribute.
 

Right, but the compiler should be able to figure that out and emit
the proper code.
- Joe

Fwd: Re: OO inheritance in a hacker style

[Joseph Ryan]

Woops, sent it to the wrong list!

- Joe

Joseph Ryan wrote:

 Luke Palmer wrote:

Austin Hastings writes:
 

Hmm. The text and examples so far have been about methods and this
seems to be about multi-methods.  Correct me if I'm wrong ...

You're wrong. Consider my example, where via single inheritance we 
reach a
"layered" list of methods, each of which replaces the previous one 
in the
namespace (parent.method superseded by child.method). This is not
multi-dispatch -- the class of the object being dispatched 
determines the
method -- but I want to modify the dispatch chain so that some upstream
class' method is "ignored".
  


It's surely possible by modifying that class's DISPATCH. 
Whether it should actually be in the language is up for debate.  I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right.  A good example might be in order... :-)
 

Well, what if the two classes you want to inherit from weren't
designed with roles in mind?  For instance, there might be two
CPAN modules that each have a dozen methods that you want to
inherit, but they each have 1 that overlap whose conflict you
want to easily resolve.
Besides, "the user is not thinking about XXX right" sounds like we
need to give a ++ to the pythonometer ;)
- Joe

Re: OO inheritance in a hacker style

[Joseph Ryan]

 Luke Palmer wrote:

Austin Hastings writes:
 

Hmm. The text and examples so far have been about methods and this
seems to be about multi-methods.  Correct me if I'm wrong ...
 

You're wrong. Consider my example, where via single inheritance we reach a
"layered" list of methods, each of which replaces the previous one in the
namespace (parent.method superseded by child.method). This is not
multi-dispatch -- the class of the object being dispatched determines the
method -- but I want to modify the dispatch chain so that some upstream
class' method is "ignored".
   

It's surely possible by modifying that class's DISPATCH.  

Whether it should actually be in the language is up for debate.  I'd say
that if you need to do this with any frequency whatsoever, you're not
thinking about roles right.  A good example might be in order... :-)
 

Well, what if the two classes you want to inherit from weren't
designed with roles in mind?  For instance, there might be two
CPAN modules that each have a dozen methods that you want to
inherit, but they each have 1 that overlap whose conflict you
want to easily resolve.
Besides, "the user is not thinking about XXX right" sounds like we
need to give a ++ to the pythonometer ;)
- Joe

Re: OO inheritance in a hacker style

[Joseph Ryan]

Dmitry Dorofeev wrote:

Hi all.
Sorry if this idea|question has been discussed or has name which i 
don't know about.




I'd like to write

Class myclass : a {
forget method area;
forget method move;
method put;
}
so methods getX, getY, size will be 'inherited'.
Methods 'area' and 'move' will be not present in myclass at all!
so $a = new myclass;
$a.area()
will return an error. At some level of inheritance methods area() and 
move() may be reimplemented again if required.


At first, I thought "Hmmm, I'm not sure if this will be useful.
Besides, what would happen in the case of multipile inheri..."
Then, it hit me.  A "forget" (or "block", or something similar)
keyword would be great in clearing up confusion with multiple
inheritance.
For instance, in an example like:

   class A {
   method a_method {}
   method common_method {}
   }
  
   class B {
   method b_method {}
   method common_method {}
   }
  
   class C is A,B { # Is that right, or am I too java-ed out?
   method c_method {}

   forget A::common_method;
   # or maybe something like: "block A::common_method"
   }
Class C would now have access to:
   A::a_method, B::b_method, C::c_method, and B::common_method
Of course, roles are another great way to prevent confusion with
multiple inheritance.  A good question would be whether something
like "forget" is useful in addition, or whether everyone should
just use roles. :)
- Joe

Re: How does perl handle HLL C?

[Joseph Ryan]

[EMAIL PROTECTED] wrote:

The subject says it all. 

As parrot is designed to be targetted by many langauges, 
how will it handle 'eval' opcodes for those different languages?

Shell out to a seperate process?

As far as Perl6 (which will be written in Perl6) goes, an easy
solution is to design the compiler so that compilition to imcc
can be done with a generalized function call, and then link in
the perl6 compiler as a module.  Eval can then just be a simple
wrapper around that, something like:
.pcc_sub _eval non_prototyped

   .param String code_to_eval
   .param PerlHash options
   .pcc_begin prototyped
   .arg code_to_eval
   .arg options
   .pcc_call _compile_perl6_code
   .local string IMCC
   .result IMCC
   .pcc_end
   .local Sub _current_eval
   .local PerlUndef result
   compile _current_eval, "IMCC", IMCC
   invokecc _current_eval
   restore result
  .pcc_begin_return
  .return result
  .pcc_end_return
.end

Something similar could be done with a C-based compiler and NCI.

- Joe

Re: This week's summary

[Joseph Ryan]

The Perl 6 Summarizer wrote:

 Do Steve Fink's debugging for him
   Steve Fink had a problem with some generated code throwing a segfault
   when it was run and, having hit the debugging wall himself, posted the
   code to the list and asked help. Leo tracked down the bug in Parrot and
   fixed it. However, that's not why this made the summary, what's
   interesting is the sample of code that the problem code was generated
   from. Here it is:
 rule thing() {
 <[a-z]>+
 }
 rule parens() {
 { print "entering parens\n"; }
 \( [  |  | \s ]* \)
 { print "leaving parens\n"; }
 }
 sub main() {
 my $t = "()()(((blah blah () blah))(blah))";
 my $t2 = $t _ ")";
 print "ok 8\n" if $t2 !~ /^  $/;
 }
   Looks tantalizing doesn't it? Someone's now going to tell me that the
   code in question has been there forever, but I'm still tantalized.
That code has been there forever. :-P

parrot/languages/perl6/t/rx/call.t - case 1

- Joe

Re: Control flow variables

[Joseph Ryan]

David Wheeler wrote:

On Tuesday, November 18, 2003, at 06:11  PM, Joseph Ryan wrote:

Not to be a jerk, but how about:

   my $is_ok = 1;
   for @array_of_random_values_and_types -> $t {
   if not some_sort_of_test($t) {
   $is_ok = 0;
   last;
   }
   }
   if $is_ok {
   yada() # has sideeffects...
   }


Isn't that just:

for @array_of_random_values_and_types, 'ok' -> $t {
when 'ok' { yada(); last }
last unless some_sort_of_test($t);
}
IOW, the topic is only 'ok' when all of the items in the array have 
been processed, which in your code is what happens when  
some_sort_of_test($t) returns a true value.


And also if @array_of_random_values contains 'ok'.

- Joe

Re: Control flow variables

[Joseph Ryan]

Damian Conway wrote:

Seiler Thomas wrote:

So... lets call a function instead:

my $is_ok = 1;
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
$is_ok = 0;
last;
}
}
if $is_ok {
yada()  # has sideeffects...
}


That's just:

for 0..6, 'ok' -> $t {
when 'ok' { yada() }
last if abs(@new[$t] - @new[$t+1]) > 3;
}
;-)

Damian 


Not to be a jerk, but how about:

   my $is_ok = 1;
   for @array_of_random_values_and_types -> $t {
   if not some_sort_of_test($t) {
   $is_ok = 0;
   last;
   }
   }
   if $is_ok {
   yada() # has sideeffects...
   }
:)

- Joe

[Fwd: Re: Proposal: parrot-compilers list]

[Joseph Ryan]

--- Begin Message ---
I 
Think this would be cool, and I will help. 
my research masters is retargetting gcj to parrot.

I am only a month into it so I have not put up a project page yet.

On Tuesday 18 November 2003 00:04, Joseph Ryan wrote:
> Pete Lomax wrote:
> >On Mon, 17 Nov 2003 11:35:51 -0800, Sterling Hughes
> >
> ><[EMAIL PROTECTED]> wrote:
> >>I think this would be a *very* cool thing.
> >
> >What he said.
>
> Ditto.
>
> - Joe

-- 
Vishal Vatsa
Dept. of Computer Sc.
NUI Maynooth


--- End Message ---

Re: Proposal: parrot-compilers list

[Joseph Ryan]

Pete Lomax wrote:

On Mon, 17 Nov 2003 11:35:51 -0800, Sterling Hughes
<[EMAIL PROTECTED]> wrote:
 

I think this would be a *very* cool thing.
   

What he said.
 

Ditto.

- Joe

Re: Nested modules

[Joseph Ryan]

Damian Conway wrote:

Larry wrote:

This kind of behaviour is more useful for nested classes, I suspect, but
it should certainly be available for nested modules as well.


So, what's the difference between a module and a class, and
why would you want dynamic namespaces?  Isn't that something
you'd use a class for?  I'm a bit confused. (-:
- Joe

Re: Nested modules

[Joseph Ryan]

Luke Palmer wrote:

So, we can have :: in names, but that doesn't represent any inherent
relationship between the module before the :: and the one after.  I
think this is an important thing to keep.
However, will it be possible to, for example, do:

   module Foo;

   module Bar { ... }

And refer to the inner module as, say, Foo.Bar.



Kinda like an inner class in Java?

A more interesting
concept, can one use variables as modules, like: 

  ::($foo)::somefunc();

except dynamic?

(On a side note, that syntax doesn't seem right, although I can't
fathom what is...)
Or some awful thing like that?

And of course this would imply the existance of anonymous modules.  Yay.

How... would that be useful?  What would one use an anonymous
module for that they couldn't do with an anonymous class?  I
thought a module was more of a compiletime distinction, while
a class was a runtime + compiletime (i.e. all encompassing)
one.
- Joe

Re: P5 "B" backend for languages/perl6 - quasi-announcement

[Joseph Ryan]

Sean O'Rourke wrote:

[EMAIL PROTECTED] (Scott Walters) writes:
 

I have work-related reason to add a "B" backend for Perl 5 to the
perl6 compiler. I'm looking at creating an assembler for Perl 5's
"B" bytecode along the lines of IMCC, and creating patches against
languages/perl6/IMCC.pm and languages/perl6/IMCC/* to conditionally,
using some sort of phrasebook, generate assembly for either Parrot
or B.
   

This would involve some nontrivial refactoring, since both are
unashamedly machine-dependent, and freely emit blocks of assembly
directly from the AST walk.  Unless B assembly is a lot like parrot
assembly, simply replacing (or factoring out) these chunks might not
be the best way.  Of course, I've never used B assembly, so discount
this impression appropriately.  Everything up to IMCC* (i.e. parsing,
tree munging, and "context" (wannabe typing)) should be fine, though.
 

I actually started to do some refactoring last night of
languages/perl6 (I've decided to put my languages/java on hold
until the class-metadata stuff is finalized.)  What kind of
refactoring would you suggest?  Should we have some sort of
generic "bytecode generation" package?
- Joe

Re: [PS] obsolete files

[Joseph Ryan]

Leopold Toetsch wrote:

Here is a list of files that I consider to be unused: 


Hmmm... obsolete... unused... sounds a lot like languages/perl6 :-P

- Joe

Re: Class metadata for PIR/assembly files

[Joseph Ryan]

Dan Sugalski wrote:

Here's the scoop:

Metadata for classes is simple. In PIR/assembly, they're noted with
.things:
 .class Foo
   .is bar
   .is baz
   .does some_thing
   .member x
   .member y
   .member z
 .ssalc
Unless someone tells me that ssalc is horribly obscene in some relatively
common language, and we may still if the translation amuses me
sufficiently.
Keywords are simple for the metadata. .class starts the declaration, has a
single parameter the name. Class declarations end with .ssalc. Each .is
defines a parent class, each .does defines an interface the class
supports, and each .member defines a PMC member slot that each object.
If a class is defined in the bytecode, it gets instantiated when the
bytecode is created. (It's a constant class, though like any other class
is mutable at runtime so it's not that constant) There is no difference
between a class created with metadata and one created by executable code
piecemeal.
Classes, when instantiated, have a backing namespace that's identical to
the class name.
We will be adding version metadata to the classes, but that's going to be
deferred.
It's OK for the code that handles PIR and assembly to ignore this for the
moment, at least until the metadata segment is better defined. Which will
be soon, though I'd rather someone else do the bytecode modification as
it's been a long time since I've had my hand in there.
This would be a good time to comment on the metadata, as I'm about to go
finish defining the ops to create classes dynamically and actually finish
the fscking object.c. code to do it.
Will there be a way to specify which methods belong to the class in the
metadata?  Or will Method namespaces just have to match class names so
that a lookup can be done?
-Joe

"::" doesn't work inside an identifier.

[Joseph Ryan]

According to the CVS log for /languages/imcc/imcc.l, "::" is now
allowed inside an identifier name.  However, when I try to create
an example like:
   .sub foo::bar
   end
   .end
It gives the error:

   error:imcc:parse error, unexpected LABEL, expecting IDENTIFIER

Is this a bug, or am I misunderstanding something?

- Joe

Re: Namespace'd subs in IMCC?

[Joseph Ryan]

Leopold Toetsch wrote:

Joseph Ryan <[EMAIL PROTECTED]> wrote:
 

From what I understand from the IMCC documentation, the ".namespace"
macro prepends the namespace name plus "::" to all names within it.
   

It's for variables only, currently.

 

I figured that this would be handy in distinguishing which class a
method belongs to without causing name clashes.  For instance:
   

 

   .namespace foo
   .sub bar
   

 

would create a method bar in the class foo, for a full name of
"foo::bar".
   

I'm not outerly sure, if imcc should even have such a functionality. Or
at least, if there is one, it should be configurable. The name mangling
is HLL dependent and there may be no general scheme to do it right for
all kind of symbols.
 

However, this doesn't seem to work.  Is this a bug, or should I be
doing something else for this type of problem?
   

It's not layed out what it should really do. I'm towards removing this
directive and let the HLL compiler deal with it.
 

Well, in that case, would it be possible to allow ":" as a valid
character for use in symbol names?
-Joe

Namespace'd subs in IMCC?

[Joseph Ryan]

From what I understand from the IMCC documentation, the ".namespace"
macro prepends the namespace name plus "::" to all names within it.
I figured that this would be handy in distinguishing which class a
method belongs to without causing name clashes.  For instance:
   .namespace foo
   .sub bar
   end
   .end
   .endnamespace foo
would create a method bar in the class foo, for a full name of
"foo::bar".
However, this doesn't seem to work.  Is this a bug, or should I be
doing something else for this type of problem?
Thanks,

- Joe

Re: Is there any way to dynamically add a method to a class?

[Joseph Ryan]

Dan Sugalski wrote:

On Mon, 25 Aug 2003, Joseph Ryan wrote:

 

So, I know how to use find_method to get a method from an object;
but is there any way to dynamically add a method to a class?
Basically, I want to do something like this:
   newclass P2, "Foo"
   new P1, P2
   
   addr I0, _Foo::somemethod
   setmethod P1, "somemethod", I0
   findmethod P0, P1, "somemethod"
   invoke

So, how do I do it? :)  
   

What's supposed to happen is that each class has a backing namespace, and 
methods all live in that namespace. Generally objects, no matter what 
their HLL class, will be PMCs that have subclassed (at the parrot level) 
ParrotObject.

Anyway, for a perl/python/ruby object of class Foo, to add a new method 
you'd just add a new sub/method name/PMC binding to the Foo namespace.

I'm a bit lost here; what does that mean?  How do I do it?  Does

   .sub _Foo::somemethod
   print "Foo-ey goodness."
   .end
add "somemethod" to the "Foo" namespace?  Or would it have to be:

   .sub Foo::somemethod
   print "Foo-ey goodness."
   .end
Thanks for the reply,

- Joe

Is there any way to dynamically add a method to a class?

[Joseph Ryan]

So, I know how to use find_method to get a method from an object;
but is there any way to dynamically add a method to a class?
Basically, I want to do something like this:
   newclass P2, "Foo"
   new P1, P2
   
   addr I0, _Foo::somemethod
   setmethod P1, "somemethod", I0
   findmethod P0, P1, "somemethod"
   invoke

So, how do I do it? :)  The only way I could figure out that might
work was to make my own pmc class that held an alias to the class
pmc itself as a property, and then treat the class itself as hash;
however that seems extremely hackish, as well as pretty slow, as it
would take an extra lookup to find the method.  Any tips would be
greatly appreciated.
- Joe

Re: Apocalypses and Exegesis...

[Joseph Ryan]

Jonathan Scott Duff wrote:

On Thu, Aug 14, 2003 at 03:00:54PM +0100, Alberto Manuel Brand?o Sim?es wrote:
 

On Thu, 2003-08-14 at 14:49, Simon Cozens wrote:
   

[EMAIL PROTECTED] (Alberto Manuel Brandão simões) writes:
 

The question is simple, and Dan can have the same problem (or him or
Larry). I am thinking on a Perl 6 book in portuguese (maybe only a
tutorial... but who knows). But that means I must write something which
will work :-)
   

Just a hint: don't try writing it and revising it as the language changes.
I wrote a Perl 6 chapter for a book in December and it is now almost unusable
due to the pace of change.
 

Yes. That's why I'm asking :-) I can start looking to apocalypses and
exegesis to have an idea of the structure and content, but not really
write them. I would need a running prototype, too. And that's more
difficult to find :)
   

Well, you can always find prototypical pieces in perl 5. For instance,
Perl6::Classes, Perl6::Currying, Perl6::Rules, etc. (note, you may have
to pull that last one out of Damian's head :-
 

There's also P6C (parrot/languages/perl6), but use with caution, as its
pretty kooky.
- Joe

Re: generic code generator? [was: subroutines and python status]

[Joseph Ryan]

Michal Wallace wrote:

On Sun, 3 Aug 2003, K Stol wrote:

 

What do you think? Want to try squishing pirate/python
and pirate/lua together? :)
 

Yeah, I like the idea. Let's try this out.
   



Well, I finished reading your report[1] and 
posted some of my (rather unorganized) thoughts
up at [2]

It does seem like there are some snags getting
languages to talk to each other, even with the
calling conventions, but even so, I'm even more
convinced now that a generic, overridable
code-generator is the way to go. 

It seems to me that if we want to maximize the
number of languages using it, the generic 
compiler shouldn't depend on anything but 
C and parrot... But until we get it working,
I'd like to stick to a dynamic language like
python/perl/lua/scheme. And, well, my code's
already in python... :) [though I'd actually
love to try out some lua 5]

What I'm picturing is a template system for
specifying chunks of IMCC. Something like this:
ast generic:
  on @while(test, body):
  % while= gensym("while")
  % endwhile = gensym("endwhile")
  % test = gensym("$I")
  {while}:
  {test} = @expr
  unless {test} goto {endwhile}
  @body
  {endwhile}:
  on @if(test, elif*, else?):
 ...
ast python(generic):
  on @while(test, body, else?):
 ...
Okay, I don't have a good syntax in mind yet,
the point is it's a template language and you
can subclass/override/extend the template. 
Maybe there's no syntax and it just uses 
cleanly coded classes in some oo language.
Or perl6 with it's grammars and rules. I
don't know.

I think that trying to define a new syntax for a new meta-language is a bad
idea.  The goal of a GCG (Generic Code Generator) should be to 
allieviate the
compiler writers of the responsiblity of generating code.  Forcing them to
generate different code doesn't help solve the problem. (-:

However, at the risk of sounding lame, what if the GCG syntax was 
instead some
sort of standard meta-language structure like YAML or XML?  As in, the 
syntax
wouldn't be a syntax at all, but just a dump of the AST with 
standardized node
names.  I think this would have a number of benefits:

1.) Instead of forcing the compiler writer to generate code, the 
compiler writer
would only have to transform the parse tree into a structure that is
name-consistant with the GCG's standard, and then use any of a number of
existing libraries to dump the tree as YAML/XML.

2.) Since there are more YAML/XML parsers than I can count implemented in
nearly modern useful language I can think of, the GCG could be generated in
any language without causing a stall on starting on the generic code 
generation
part of the project. (you know, the important part)

3.) It would be possible to handle language-specific nodes by defining some
sort of "raw" node whose value could be raw imcc code.
Anyways, just a few thoughts.  A tool like this would be *very* useful,
I think.  Good luck. (-:
- Joe

JVM->PIR translator (was: Re: subroutines and python status)

[Joseph Ryan]

Leopold Toetsch wrote:

Luke Palmer <[EMAIL PROTECTED]> wrote:


You mind submitting a patch to put this in the languages/pirate

I'd appreciate that very much. Pie-thon, here we come ...

Speaking of adding new projects to languages, I have a partially complete
JVM->PIR translator done.  It's complete, with the exception of:
1: The two threading ops arent translated
2: I need to translate the core libraries.  I'm hoping GNU Classpath 
will be of
  some help here.
3: I'm missing some runtime exceptions, which I just havent gotten around to
  yet.
 
Other than that, its pretty complete.

However, the code it generates isn't quite runnable.  Pasm seems to be 
missing
a few instructions, specifically add_method and add_attribute instructions.
So, I just made them up.  As you can imagine, this causes a few errors 
:)  That
means that beyond trivial cases, the code is mostly untested.

So, would anyone want this in the tree?  Or should I wait until it is better
tested and documented?
You take a look at it at:

http://jryan.perlmonk.org/images/jirate.tar.gz

Let me know what you think.

- Joe

Re: approaching python

[Joseph Ryan]

Benjamin Goldberg wrote:

K Stol wrote:

The register stuff, I presume, is register allocation and the like? When
targeting IMCC, you can use an infinite amount of registers. Just keep a
counter in the code generator, each time a new register is needed, just
increment the counter and add a "${S|N|I|P}" in front of it (example:
$P1). IMCC does register allocation and spilling.
So this is not really difficult.
Nono, the problem isn't that python uses *more* registers than
, but rather, that it doesn't use registers at all.  Instead,
it uses a stack.  So, for example, python's add instruction might get
translated into the following pir or pasm code:
  restore P0
  restore P1
  clone P0, P0
  add P0, P1
  save P0
Needless to say, this is not efficient, due to how slow parrot's push
and pop operations are.
Well, thats because you're trying to make a register machine act like a
stack machine.  It would be more efficient to translate add as:
$P2 = $P0 + $P1

That is to say, map stack positions to registers by simulating the
stack while walking each op during translation time, rather than
during runtime.  So, in this case, the code that translates the add
instruction might look something like:
   translate_add_op {
   pop variable1 off of simulated stack
   pop variable2 off of simulated stack
   create new temp pmc
   push new temp_pmc onto simulated stack
   print temp_pmc's name
   print " = "
   print variable1's name
   print " + "
   print variable2's name
   }
So, after this code, our simulated stack is depleted by two items
(the operands), and then replenished by one (the result); this
makes it act exactly like the real stack, except that we are
manipulating the registers rather than the values.
Hmm...  If imcc is smart enough, (or perhaps I should say, when the flow
control is simple/clear enough) it should be able to see when a value is
pushed onto the stack, and later popped off, when there are enough
registers free that we could have stored it in a spare register instead
of on the stack.  That is, a sort of register *un*spilling.
Doesn't IMCC already do this?

- Joe

Re: Literal tests [was: Help with setting up Perl6]

[Joseph Ryan]

Sean O'Rourke <[EMAIL PROTECTED]> wrote:


On Thu, 12 Dec 2002, Jared Rhine wrote:
> On to some tests, although I'm curious to see how tests of literals
> turn out.  Probably a lot of comparisons between different
> representations of the same thing.

Warning: most of the tests won't work now because the languages/perl6 is
woefully incomplete, and because a lot of it was implemented before
literals existed in their current form.  If someone wants to get up to
speed on the languages/perl6, this would be a great way to do it.  If not,
I'll put these on top of the stack for next time I have Parrot time
(hopefully over break).



I was planning on getting back to work on languages/perl6 as well,
since I too am now on break.  I'll update the literal defs if noone
else wants to; however, I was hoping to clean up IMCC.pm before I do
any more damage to the parser ;)

_
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: String Literals, take 1

[Joseph Ryan]

(* Note: Please reply to [EMAIL PROTECTED] *)
(* Don't reply to this hotmail address!  I'm deleting it tomarrow! *)
(* Fight the urge! *)



: Jonathan Scott Duff <[EMAIL PROTECTED]>

: Joseph Ryan <[EMAIL PROTECTED]>



> Anyways, here's a first draft of the string documentation ...

I didn't see any mention of vstrings  (e.g. tokens of the form
v5.8.0.  I also got the impression from a response Larry made to one
of the emails in the thread on numbers that the leading v might be
optional)


Good point, I missed them; interestingly, I can't find a reference to
them in perl5's perlop.



Also, I didn't see mention of the string context coercer which though
it doesn't really have to do with literals, probably should have a
reference here somewhere.


I disagree, that should go in perlop. (Same with the concat operator, 
whatever that will be when that section is written)


> - Larry was never specific as to how hashes interpolate; anyone have
>   any ideas?

I'd think that hashes would interpolate as a list of
key,value,key,value,etc.

BTW, how do pairs interpolate?


A hash is a set of pairs, so pair interpolation needs to be defined before 
hash interpolation can.  I like the way the RFC suggests that
hashes interpolate, given that $/ and $" are upgraded to perl6 terms.


> =pod
>
> =head1 Strings
>
> A string is a literal value that represents a sequence of characters.
> A string object is formed when a sequence of characters is enclosed in
> one of the quoting operators, of which there are 3 types:
> Interpolating, Non-Interpolating, and Here-Docs;

This classification doesn't make sense to me. Here-docs are just another
quoting operator which can be interpolating or non-interpolating..


Yes, thats true, but Here-Docs are so... different.  Different enough to
get their own section.  You are right that the sentance is unclear, however.



Also, the whole idea of "interpolation" probably needs to be
explained up front.  Maybe something like this:

There are two types of quoting operators: interpolating and
non-interpolating. In interpolating constructs, the value of a
variable is substituted for the variable name within the string
and certain characters have special meaning when preceded by a
backslash (C<\>). In non-interpolating constructs, a variable
name that appears within the string is used as-is. The simplest
examples of these two types of quoting operators are strings
delimited by double (interpolating) and single quotes
(non-interpolating). For example:

		'The quick brown $animal'
		"The quick brown $animal"

In the first string, perl will take each character literally and
perform no special processing. In the second string, the value
of the variable $animal is inserted within the string at that
location. If $animal had had the value "fox", then the second
string would have become "The quick brown fox".

	More on the various quoting operators below.



Sounds good to me, except that the backslash is special in single-quoted
strings too.  The only real non-interpolated construct is the single-
quoted Here-Doc.


> =head2 Non-Interpolating Constructs

oh, a minor nit here ... tackle the items in the order that you first
list them.  In your 3 type classification you mention interpolating
first then non-interpolating, so you should start off talking about
interpolating or switch the order in the list.


Woops. :)


Joseph F. Ryan.

_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

Re: String Literals, take 1

[Joseph Ryan]

: Luke Palmer <[EMAIL PROTECTED]>

: Joseph F. Ryan <[EMAIL PROTECTED]>




> Perhaps only first level references should stringify nicely, and inner
> references stringify perl5 style.  I think that if Data::Dumper style
> stringification is wanted, then a C<< use Data::Dumper; >> shouldn't
> anger too many people.  This would solve circular referencing, at
> least.

That's the question of whether stringification will strictly be
serializing, or whether that will be a method call and stringification
should "look pretty" or "be useful".  I prefer the latter.


Same.



> >Is this true?  We changed the numeric octal shorthand base to 0c777, so
> >what sense does \o for octal charcters make?  (Unfornatly, we can't use 
\c,
> >since that's taken for control charcters.)  IIRC, somebody had 
mentioned
> >just getting rid of \o altogether.  People don't think in octal.
>
> Last time I remember an official decision, it was \o; however, I've
> been a bit out of the loop that last couple of days, so I could be
> wrong here.

I remember hearing that the octal shorthand was 0o777.

Right, so octal stringification shorthand would be "\o777".



> >>Within an interpolated string, interpolation of expressions can be
> >>stopped by \Q.
> >(Which acts somewhat like a non-breaking space.)

I though \Q...\E was leaving in favor of \Q{...}


It is; however, there is a null \Q that acts to break up
interpolated expressions; take a look at

http://www.perl.com/pub/a/2001/05/03/wall.html#rfc 328: single quotes don't 
interpolate \' and \\

Under the "Weird Brackets" section.


> >I think we need a non-optional space to follow the << in the case of
> >double-quotes to disambuilage with <<>> qw lists.
>
> Apoc 2 explicitly states that the space will be optional.

But Apoc 2 thought that <> was spelled < qw stuff >.  I
really don't know whether it should or not.


Thats true; why exactly was <> abandoned in favor of <<>> in the first 
place?

_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: String Literals, take 1

[Joseph Ryan]

(* Note: Please reply to [EMAIL PROTECTED] *)


: Arcadi Shehter <[EMAIL PROTECTED]>

: "Joseph Ryan" <[EMAIL PROTECTED]>




issue :
  * space is allowed (OR NOT ???)
between qq ( and friends ) and following delimiter

qq ( ... ) ;
qq ) ... ( ;
qq ' ... ' ; ???
qq | ... | ;


These should be fine.


qq # ... # ; ???


Should be alright as long as there is no space between the operator and
the delimiter.


qq : ... : ; ???


I'd say no, just incase someone defines their own quoting operator to
which some sort of property can be applied.

Joseph F. Ryan
[EMAIL PROTECTED]

_
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: String Literals, take 1

[Joseph Ryan]

From: James Mastros <[EMAIL PROTECTED]>

On 11/29/2002 7:40 PM, Joseph Ryan wrote:


(*Note: Please reply to [EMAIL PROTECTED], as this is only a temporary email 
address)

- References and Object stringification hasn't been defined.

I belive it goes somthing like this:
All objects define a .AS_STRING method.  This method is called to stringify 
the object.  The builtin types have builtin .AS_STRINGs, the primitive 
types autopromote.  All strinification thus follows the same logical model, 
even if the implementation doesn't.

So, should all scalars stringify as a Str?  Or should scalar be the
default type, which all other types inherit from, redefining their
AS_STRING as necessary?


The default .AS_STRING for Strings is obvious.  Int and Num stringify to a 
decimal number (using the e exponential form if it is shorter?).

I hope not; if someone wants a number in e form, they should specify it
themselves.




- If References interpolate in some sort of readable way, how do
 multi-leveled references interpolate, and how do self-referring
 data structures interpolate?

Multi-leveled: The outer .AS_STRING calls it's members' .AS_STRINGs. 
Circular: I have no idea.

Perhaps only first level references should stringify nicely, and inner
references stringify perl5 style.  I think that if Data::Dumper style
stringification is wanted, then a C<< use Data::Dumper; >> shouldn't
anger too many people.  This would solve circular referencing, at
least.



Possibly misleading: Leads people to think that a string is an array of 
chars, like in C?  (I don't think so, but new-to-perl people might.  I'm 
being nitpicky.)

Good point, I didn't even think about that.


This should be moved to general documentation for pick-a-delimiter 
functions.  Also, a rigirous definition of a pair of delimiters might be 
nice.  I'll look at unicode.org and see if I can find somthing out.

I don't think so; there are only 5 operators that can do this:
q//, qq//, tr///, s///, and m//; however, regular expressions have
different delimeter rules (specifically, they can't use "()"), and are
also parsed different.  I think they should be explained in the regular
expression section.


Is the \qq{} construct a pick-a-delimiter thing?  I think it should be, for 
parallelisim with the qq() operator.

I hope not, {} is much easier to read (and parse).  Anyways, Apoc 2
only mentions {}.  Any delimiter could have been implied, but I just
didn't read it that way.


I thought it was named <> or «foo bar baz» or qw().  (That 
middle one should be U+00AB and U+00BB, \N{LEFT-POINTING DOUBLE ANGLE 
QUOTATION MARK} and \N{RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK}. 
Additionaly, I'm fairly certian, the Unicode ops could be either direction. 
 I think there was a reason for that, but I don't remember what.

It was <> in Apoc 2; however, if it changed in a discussion on
perl6-language, I'm unaware of it.




   \ttab

\U{9}

   \nnewline

\U{10}

   \rreturn

\U{13}

   \fform feed

\U{12}

   \bbackspace

\U{8}

   \aalarm (bell)

\U{7}

   \eescape

\U{27}

   \b10binary char
   \o33octal char

Is this true?  We changed the numeric octal shorthand base to 0c777, so 
what sense does \o for octal charcters make?  (Unfornatly, we can't use \c, 
since that's taken for control charcters.)  IIRC, somebody had mentioned 
just getting rid of \o altogether.  People don't think in octal.

Last time I remember an official decision, it was \o; however, I've
been a bit out of the loop that last couple of days, so I could be
wrong here.


   \x1bhex char

Specificly, \x must be followed by exactly two hex digits, or do we DWIM 
with one (IE, if there is only one character in 0-9A-Fa-f after the \x, do 
we

Do we what? :)
Perl5's semantics are to treat it as a 1 digit number, so \x1 becomes
\x01.  That's good enough for me.





   \N{name}named Unicode character

Suggested extension: \U{13#ac05} is Unicode character number ac05 in base 
13.  Any perl expression will do inside the {}s.

I don't think so; any text within a {} should be treated like an
interpolating string.  (or a non-interpolating string, in the case of
\q{} and \Q{})




   \Q{}Escape all characters that need escaping
   within the current string (except "}")

Escape all characters in [^A-Za-z0-9] within the {}'d part with 
backslashes.  ("that need escaping" is inexact.)

Yeah, you're right.




Within an interpolated string, interpolation of expressions can be
stopped by \Q.

(Which acts somewhat like a non-breaking space.)


Say wha?

Do you mean that \Q acts zero-width?




The collected standard output of the
command is returned; standard error is unaffected.

Standard error is passed o

Re: String Literals, take 1

[Joseph Ryan]

First, apologies for the typos; fixed.


Do you mean \Q or \Q{}, or both ?


\Q{}; \Q{} is different than \Q, at least according to the Apocalypse.



  \Q{}Escape all characters that need escaping
  from this point on in the current string (except "}")



Yeah.



Then
print "@list\Q{0}"; # prints '1 20'


Yep.


Joseph F. Ryan
[EMAIL PROTECTED]

_
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

String Literals, take 1

[Joseph Ryan]

First of all, apologies for sending through Hotmail; I'm home for the
weekend, and have no access to email.  However, I figured I should
send this out as soon as I finished so that people have something to
think about besides numbers :)

Anyways, here's a first draft of the string documentation, I've put
comments in as:

# comment.

Known issues:

- Larry was never specific as to how hashes interpolate; anyone have
 any ideas?
- References and Object stringification hasn't been defined.
- If References interpolate in some sort of readable way, how do
 multi-leveled references interpolate, and how do self-referring
 data structures interpolate?
- I assumed escaping would be similar to perl5's, so I just used the
 table from perl5's perlop.


Joseph F. Ryan
[EMAIL PROTECTED]



=pod

=head1 Strings

A string is a literal value that represents a sequence of characters.
A string object is formed when a sequence of characters is enclosed in
one of the quoting operators, of which there are 3 types:
Interpolating, Non-Interpolating, and Here-Docs; each are explained
below.

=head2 Non-Interpolating Constructs

Non-Interpolating constructs are strings in which expressions do not
interpolate, or expand.  The one exception to this is that the
backslash character, \, will always escape the character that
immediately follows the it.

The base form for a non-interpolating string is the single-quoted
string: 'string'.  However, non-interpolating strings can also be formed
with the q() operator.  The q() operator allows strings to be made with
any non-space, non-letter, non-digit character as the delimeter instead
of '.  In addition, if the starting delimeter is a part of a paired
set, such as (, [, <, or {, then the closing delimeter may be the
matching member of the set.  In addition, the reverse holds true;
delimeters which are the tail end of a pair may use the starting item
as the closing delimeter.

=over 3
Examples:

	$string = 'string'  # $string = 'string'
	$string = q|string| # $string = 'string'
	$string = q(string) # $string = 'string'
	$string = q]string[ # $string = 'string'
=back


=head3 Embedding Interpolated Strings

It is also possible to embed an interpolating string within a non-
interpolating string by the use of the \qq{} construct.  A string
inside a \qq{} constructs acts exactly as if it were an interpolated
string.  Note that any end-brackets, "}", must be escaped within the
the \qq{} construct so that the parser can read it correctly.

=over 3
Examples ( assuming C<< $var="two" >> ):

	$string = 'one \qq{$var} two'# $string = 'one two three'
	$string = 'one\qq{ {$var\} }two' # $string = 'one {two} three'
=back

=head3 <>; expanding a string as a list.

A set of braces is a special op that evaluates into the list of words
contained, using whitespace as the delimeter.  It is similar to qw()
from perl5, and can be thought of as roughly equivalent to:
C<< "STRING".split(' ') >>

=over 3
Examples:

	@array = ; # @array = ('one', 'two', 'three');
	@array =  three>; # @array = ('one', '<>', 'three');
=back

=head2 Interpolating Constructs

Interpolating constructs are another form of string in which variables
that are embedded into the string are expanded into their value at
runtime.  Interpolated strings are formed using the double quote:
"string".  In addition, qq() is a synonym for "", which is similar to
q() being a synoynm for ''.  The rules for interpolation are as
follows:

=head3 Interpolation Rules

=over 3

=item Scalars: C<"$scalar">, C<"$(expression)">
Non-Reference scalars will simply interpolate as their value.  $()
forces its expression into scalar context, which is then handled as
either a scalar or a reference, depending on how expression evaluates.

=item Lists: C<"@list">, C<"@(expression)">
Arrays and lists are interpolated by joining their list elements by the
list's separator property, which is by default a space.  Therfore, the
following two expressions are equivalant:

=over 3
	print "@list";
	print "" ~ @list.join(@list.separator) ~ "";
=back

=item Hashes: C<"%hash">, C<"%(expression)">
# RFC 237 proposes: join( $/, map { qq($_$"$hash{$_}) } keys %hash )
# However, Larry never made any definite decision.
# Well, maybe he did, and just didn't tell anyone :)

=item Subroutines and Methods: C<"&sub($a1,$a2)">, C<"$obj.meth($a)">
Subroutines and Methods will interpolate their return value into the
string, which will be handled in whichever type the return value is.
Same for object methods.  Note that parens B required during
interpolation so that the parser can disambiguate between object
methods and object members.

=item References C<"$ref">
# Behaivor not defined

=item Default Object Stringification C<"$obj">
# Behaivor not defined

=item Escaped Characters
# Basically the same as Perl5; also, how are locale semantics handled?

   \t			tab
   \n			newline
   \r			return
   \f			form feed
   \b			backspace
   \a			alarm (bell)
   \e			escape
   \b10		binary char
   \o33		o