After a complete cygwin reinstall, I've finally gotten parrot to
install and pass 100% tests. Ok, great.
However, perl6 seems to be breaking. "Seems" meaning that 100% of
the tests are failing. This is bad.
I've mananged to trace the error to the imcc phase. The outputted
imcc code seems corr
Leopold Toetsch wrote:
So it seems, that for multiple code segments, we'll have to take the
PackFile_ConstTable out of the structure and include
file/line/debug/whatever information. This would look like:
packfile aka interpreter->code:
- constants
- code_segment[]
- byte_code
- byte_c
On Thu, Jan 16, 2003 at 11:25:34AM -0800, Tupshin Harper said:
> The ability to download autodia off of the primary site and the mirror
> is unfortunately broken.
Fwd-d to the author and apparently it's fixed now.
Simon
Dear list,
Please excuse my ignorance, and if the answer is just RTFM, then please
shoot me.
What is the plan for declaring "Object Oriented APIs" in parrot.
In dotnet il, you have a OO concept built into the assembly,
but parrot seems to be missing this. Is there a plan for supporting
the high l
Joseph F. Ryan wrote:
After a complete cygwin reinstall, I've finally gotten parrot to
install and pass 100% tests. Ok, great.
However, perl6 seems to be breaking. "Seems" meaning that 100% of
the tests are failing. This is bad.error (test.warn) of:
last token = []
(error) line 27: parse e
On Thu, Jan 16, 2003 at 10:46:21AM -0800, Marc M. Adkins wrote:
> I have a Perl program that processes Perl source and generates fake C++
> headers that doxygen will process. Doxygen doesn't have a hook for adding a
I've done the same thing, you can get it or see the output here:
http://smop.org/
cool!
i will try that out.
mike
--- Bart Schuller <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 16, 2003 at 10:46:21AM -0800, Marc M. Adkins wrote:
> > I have a Perl program that processes Perl source and generates fake
> C++
> > headers that doxygen will process. Doxygen doesn't have a hook for
> add
On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote:
> On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote:
> > The headers I received make no mention of character set - does your mailer
> > mark the message in any way? If not, then STMP will assume it's good old
> > 7 bi
At 7:13 AM -0800 1/17/03, David Storrs wrote:
Do we at least all agree that it would be a good thing if Unicode were
the default character set for everything, everywhere? That is,
editors, xterms, keyboards, etc?
No. No, we don't.
--
Dan
On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
> At 7:13 AM -0800 1/17/03, David Storrs wrote:
> >Do we at least all agree that it would be a good thing if Unicode were
> >the default character set for everything, everywhere? That is,
> >editors, xterms, keyboards, etc?
>
> No. No,
--- David Storrs <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 16, 2003 at 04:14:20PM -0600, Jonathan Scott Duff wrote:
> > On Thu, Jan 16, 2003 at 10:07:13PM +, Nicholas Clark wrote:
> > > The headers I received make no mention of character set - does
> your mailer
> > > mark the message in any wa
* David Storrs <[EMAIL PROTECTED]> [2003-01-17 19:29:25]:
> On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
> > At 7:13 AM -0800 1/17/03, David Storrs wrote:
> > >Do we at least all agree that it would be a good thing if Unicode were
> > >the default character set for everything, ever
At 8:08 AM -0800 1/17/03, David Storrs wrote:
On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
At 7:13 AM -0800 1/17/03, David Storrs wrote:
>Do we at least all agree that it would be a good thing if Unicode were
>the default character set for everything, everywhere? That is,
>e
On Fri, Jan 17, 2003 at 12:19:01PM -0500, Dan Sugalski wrote:
> At 8:08 AM -0800 1/17/03, David Storrs wrote:
> >On Fri, Jan 17, 2003 at 10:59:57AM -0500, Dan Sugalski wrote:
> >> At 7:13 AM -0800 1/17/03, David Storrs wrote:
> >> >
> >> >Do we at least all agree that it would be a good thing if
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~> and <~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = grep { ... } <~ map { ...
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> So, to bring this thread back on track *again*, I hopefully offer this
> summary.
>
>
> 1) Damian's idea of using ~> and <~ as L2R and R2L is well-liked. Thus:
>
>@out = grep { ... } map { ... } @in; # (1) (perl5)
>
> be
Mr. Nobody:
# I have to wonder how many people actually like this syntax,
# and how many only say they do because it's Damian Conway who
# proposed it. And map/grep aren't "specialized syntax", you
IIRC Damian also supports Unicode operators (and may have originated the
idea), and obviously man
[EMAIL PROTECTED] (Mr. Nobody) writes:
> I have to wonder how many people actually like this syntax, and how many only
> say they do because it's Damian Conway who proposed it. And map/grep aren't
> "specialized syntax", you could do the same thing with a sub with a prototype
> of (&block, *@list).
[EMAIL PROTECTED] (Brent Dax) writes:
> # could do the same thing with a sub with a prototype of
> # (&block, *@list).
>
> Great. That could mean it won't work right for MyCustomArrayLikeThing.
Can you explain what you mean by this, because it's not apparent to me
that your statement is in any
Mr. Nobody said:
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>>
>> So, to bring this thread back on track *again*, I hopefully offer this
>> summary.
>>
>>
>> 1) Damian's idea of using ~> and <~ as L2R and R2L is well-liked. Thus:
>>
>>@out = grep { ... } map { ... } @in; #
At 10:28 AM -0600 1/15/03, Garrett Goebel wrote:
Peter Haworth wrote:
Dan Sugalski wrote:
> Adriano wrote:
> >
> >I think what Jonathan asked for was an operator for
> >returning a method (as an object) which can be invoked
> >later with some arguments (or even applied with a
> >partial li
Leopold Toetsch wrote:
Joseph F. Ryan wrote:
However, perl6 seems to be breaking. "Seems" meaning that 100% of
the tests are failing. This is bad.error (test.warn) of:
I did make a little change in imcc.l, but I have no difference in test
results.
$ make test
$ perl6 --test -r
both give
At 11:44 AM -0500 1/15/03, attriel wrote:
>> > >I think what Jonathan asked for was an operator for
> >returning a method (as an object) which can be invoked
> >later with some arguments (or even applied with a
> >partial list of arguments for currying).
> >
> >This would be a lot more usef
Here is a snippet from my last check in:
..
/cvs/public/parrot/include/parrot/interpreter.h,v <-- interpreter.h
new revision: 1.62; previous revision: 1.61
done
Cannot open file /tmp/#cvs.lastdir.27414: No such file or directory
Access allowed: Pers
At 11:44 AM -0600 1/15/03, Garrett Goebel wrote:
From: attriel [mailto:[EMAIL PROTECTED]]
>> > >I think what Jonathan asked for was an operator for
>> > >returning a method (as an object) which can be invoked
>> > >later with some arguments (or even applied with a
>> > >partial list of argum
At 9:38 AM -0800 1/15/03, Jonathan Sillito wrote:
I realize this will vary from language to language, but generally we will
need a PMC that encapsulates a method (and responds to the invoke vtable
method like Sub, or maybe the Sub PMC could do?). This python code is
interesting:
a = A()
a.f()
At 3:06 PM -0500 1/15/03, Christopher Armstrong wrote:
On Wed, Jan 15, 2003 at 01:57:28AM -0500, Dan Sugalski wrote:
At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:
>But who knows, maybe it could be made modular enough (i.e., more
>interface-oriented?) to allow the best of both worlds -
At 8:54 PM + 1/15/03, Nicholas Clark wrote:
On Wed, Jan 15, 2003 at 01:00:59AM -0500, Dan Sugalski wrote:
At 8:53 PM -0800 1/14/03, Adriano wrote:
>I think what Jonathan asked for was an operator for returning a
>method (as an object) which can be invoked later with some arguments
>(or
At 3:03 PM -0800 1/15/03, Jonathan Sillito wrote:
Sounds like we want objects *and* classes to support:
static_attribs - which are defined at compile time and
accessed by offset probably stored in an array.
dynamic_attribs - which come and go at run time and are
generally accessed by name and li
At 4:53 PM + 1/14/03, Bernhard Schmalhofer (via RT) wrote:
I have been looking at the ops 'neg' and 'abs' in core.ops. I have been
adding testcase in t/op/arithmetics.t and found a couple of problematic
cases.
Sorry this one sat. I want to apply it, but the test patch looks to
be reversed,
On Fri, Jan 17, 2003 at 12:21:33PM -0500, Dan Sugalski wrote:
> Sorry this one sat. I want to apply it, but the test patch looks to
On Tue, Jan 14, 2003 at 04:53:25PM +, Bernhard Schmalhofer wrote:
> For the operator 'abs' I use the functions 'abs()' and 'fabs()' from the
> C math library. '
--- Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 17, 2003 at 12:21:33PM -0500, Dan Sugalski wrote:
> > Sorry this one sat. I want to apply it, but the test patch looks to
>
> On Tue, Jan 14, 2003 at 04:53:25PM +, Bernhard Schmalhofer wrote:
> > For the operator 'abs' I use the func
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #20374]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20374 >
The Solaris tinderboxes are failing with the unhelpful message
"PANIC: Unknown signat
At 6:42 PM + 1/17/03, Andy Dougherty (via RT) wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #20374]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=20374 >
The Solaris tinderboxes are fa
Simon Cozens:
# [EMAIL PROTECTED] (Brent Dax) writes:
# > # could do the same thing with a sub with a prototype of
# > # (&block, *@list).
# >
# > Great. That could mean it won't work right for
# > MyCustomArrayLikeThing.
#
# Can you explain what you mean by this, because it's not
# apparent t
On Fri, Jan 17, 2003 at 09:57:47AM -0800, Mr. Nobody wrote:
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> >@out = grep { ... } <~ map { ... } <~ @in; # (2) (perl6)
> >@out <~ grep { ... } <~ map { ... } <~ @in; # (3)
> >@in ~> map { ... } ~> grep { ... } ~> @out; #
--- Thom Boyer <[EMAIL PROTECTED]> wrote:
> Mr. Nobody [mailto:[EMAIL PROTECTED]] groused:
> >I have to wonder how many people actually like this syntax, and how many
> only
> >say they do because it's Damian Conway who proposed it.
>
> Some of us like it because we've wanted something like it fo
You've overlooked ~|> or ~> or whatever that operates on context by
default.
given @foo {
~> classify ~> @categories;
~> sort -> @sorted_foo;
~> improve ~> @bar;
};
Personally, I'd like to see that syntax improved a little.
Anyway, I'd suggest that the order of execution o
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Mr. Nobody) writes:
> > I have to wonder how many people actually like this syntax, and how many only
> > say they do because it's Damian Conway who proposed it. And map/grep aren't
> > "specialized syntax", you coul
[EMAIL PROTECTED] (Brent Dax) writes:
> # > # could do the same thing with a sub with a prototype of
> # > # (&block, *@list).
>
> OK. Let's say I'm implementing HugeOnDiskArray, and instead of slurping
> the array in and grepping over it, I want to grab the elements one at a
> time, run them thr
[EMAIL PROTECTED] (Paul Johnson) writes:
> I trust that we are all sufficiently grown up and devoid of marketing hype
> that we can judge suggestions on their own merit.
Do you need pointing to the archives at this point?
--
DYSFUNCTION:
The Only Consistent Feature of All of Your Dissatisfyi
> I have to wonder how many people actually like this syntax, and how
> many only say they do because it's Damian Conway who proposed it.
> And map/grep aren't "specialized syntax", you could do the same
> thing with a sub with a prototype of (&block, *@list).
I have to say that I am not speciall
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Simon Cozens:
> # [EMAIL PROTECTED] (Brent Dax) writes:
> # > # could do the same thing with a sub with a prototype of
> # > # (&block, *@list).
> # >
> # > Great. That could mean it won't work right for
> # > MyCustomArrayLikeThing.
> #
> # Can you e
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Mr. Nobody) writes:
> > I have to wonder how many people actually like this syntax, and how
> > many only say they do because it's Damian Conway who proposed it.
> > And map/grep aren't "specialized syntax", you coul
I'd like to point out one thing that I'm not sure of. It seems like the
original proposal only allowed for the operators to change terms around.
So given the same (1)-(4) from the message, (4) is exactly the same as (1), and
(2) and (3) are exactly the same as each other and as
@out =
* Mr. Nobody <[EMAIL PROTECTED]> [2003-01-17 19:55:41]:
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> >@out <~ grep { ... } <~ map { ... } <~ @in; # (3)
> >@in ~> map { ... } ~> grep { ... } ~> @out; # (4)
> I have to wonder how many people actually like this syntax, and how
"Mr. Nobody" <[EMAIL PROTECTED]> wrote :
> I have to wonder how many people actually like this syntax, and how many
only
> say they do because it's Damian Conway who proposed it. And map/grep
aren't
> "specialized syntax", you could do the same thing with a sub with a
prototype
> of (&block, *@list
On Friday, January 17, 2003, at 09:57 AM, Mr. Nobody wrote:
And map/grep aren't "specialized syntax", you could do the same thing
with a sub with a prototype of (&block, *@list).
The specialized part is that, in perl5, it's:
@out = grep { ... } map { ... } @in;
instead of:
@out = grep {
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> ...the absence of the commas is what's special. If they were normal
> functions/subroutines/methods/whatever, you would need a comma after
> the first argument
This is plainly untrue. See the "perlsub" documentation, which talks about
"creating your o
Michael Lazzaro wrote:
So, to bring this thread back on track *again*, I hopefully offer this
summary.
1) Damian's idea of using ~> and <~ as L2R and R2L is well-liked. Thus:
@out = grep { ... } map { ... } @in; # (1) (perl5)
becomes any of the following:
@out = gr
On Friday, January 17, 2003, at 10:41 AM, Dave Whipp wrote:
But then we shift our perception to think that -> is an L2R pipe into a
block: not an anonymous sub composer. Similarly, the C function is
a strange thing sends its elements down the pipe, one-by-one -- its not
a loop at afterall! (A ju
Buddha Buck:
# My impression was that ~> and <~ were more general than that,
# and mainly
# did syntax-rewriting.
Correct.
# So (4) above was translated in the parsing stage to be
# exactly identical
# to (1), by the following conversions:
#
## original (4)
#@in ~> map { ... } ~> gre
On 2003-01-17 at 19:00:04, Simon Cozens wrote:
> This is plainly untrue. See the "perlsub" documentation, which talks about
> "creating your own syntax" with the & prototype. You can do all this in
> Perl 5, and it saddens me that some of the people redesigning Perl don't
> know what Perl can do.
W
On Fri, Jan 17, 2003 at 11:03:43AM -0800, Michael Lazzaro wrote:
>
> And note that as pretty as -> is, we couldn't have <- for piping
> because it would conflict rather strongly things like
>
> if ($a<-5)# (negative five, or pipelike?)
Pipelike. Longest token rule.
--Dks
On 2003-01-17 at 14:15:46, I wrote:
> But as I see it, the real problem being solved by the new syntax
> is that grep and map can exist solely as methods on some class
> in the inheritance tree of @arrays, no global functions required.
> That is a Good Thing.
I realize that such also be true if w
Brent Dax wrote:
Incorrect. The translation sequence is:
@in ~> map { ... } ~> grep { ... } ~> @out
((@in ~> map { ... }) ~> grep { ... }) ~> @out
((@in.map({ ... })).grep({ ... })) ~> @out
@out=((@in.map({ ... })).grep({ ... }))
@[EMAIL PROTECTED]({ ... }).grep({ ... })
The only differen
On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote:
[EMAIL PROTECTED] (Michael Lazzaro) writes:
...the absence of the commas is what's special. If they were normal
functions/subroutines/methods/whatever, you would need a comma after
the first argument
This is plainly untrue. See th
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Friday, January 17, 2003, at 11:00 AM, Simon Cozens wrote:
> > [EMAIL PROTECTED] (Michael Lazzaro) writes:
> >> ...the absence of the commas is what's special. If they were normal
> >> functions/subroutines/methods/whatever, you would need a
Dave Whipp wrote:
But the squiggly arrow doesn't seem right. I contrast it with the anonymous
sub composer ("->") which was chosen, I think, because it worked well in
the context of a C loop. Consider the following:
$\ = "|"; $, = ",";
Except, of course, those won't exist in Perl 6.
You wan
Andy Dougherty (via RT) wrote:
In this case, I suspect it's failing to match "pIt", which was recently
added to interpeter.c:setup_default_compreg().
Nothing to suspect here ;-)
In "[CVS ci] eval #1" I wrote:
Missing and left for an exercise for Joe Other Parrothacker:
build_nativecall.pl lac
At 9:38 PM +0100 1/17/03, Leopold Toetsch wrote:
Andy Dougherty (via RT) wrote:
In this case, I suspect it's failing to match "pIt", which was recently
added to interpeter.c:setup_default_compreg().
Nothing to suspect here ;-)
In "[CVS ci] eval #1" I wrote:
Missing and left for an exercise fo
On Fri, 17 Jan 2003, Leopold Toetsch wrote:
> Andy Dougherty (via RT) wrote:
>
> > In this case, I suspect it's failing to match "pIt", which was recently
> > added to interpeter.c:setup_default_compreg().
>
> Nothing to suspect here ;-)
> In "[CVS ci] eval #1" I wrote:
>
> Missing and left for
Dan Sugalski wrote:
I think we can stand 3 failing tests for one or two days, when the
reason is well known.
Three? Every test fails under OS X because of this...
Oops, dynamic vs static NCI..., sorry.
If not done yet, I'll fix this tomorrow.
leo
--- Damian Conway <[EMAIL PROTECTED]> wrote:
> We should bear in mind that Larry has had some health issues.
> And that he's currently unemployed with four children to support.
Maybe he could find work hacking perl. I've heard he's pretty good...
;-)
=Austin
Mark J. Reed wrote:
On 2003-01-17 at 19:00:04, Simon Cozens wrote:
This is plainly untrue. See the "perlsub" documentation, which talks about
"creating your own syntax" with the & prototype. You can do all this in
Perl 5, and it saddens me that some of the people redesigning Perl don't
know wh
Buddha Buck wrote:
My impression was that ~> and <~ were more general than that, and mainly
did syntax-rewriting.
You can certainly think of it as syntax rewriting
(though, personally, I don't).
What ~> and <~ do is to (respectively) allow arguments and invocants to
appear in a different posit
Buddha Buck wrote:
Brent Dax wrote:
Incorrect.
Hmmm, I must have misunderstood Damian's suggestion when he said
(quoting Damian Conway)
Suppose ~> takes its left argument and binds it to
the end of the argument list of its right argument,
then evaluates that right argument an
On 2003-01-17 at 17:17:03, Joseph F. Ryan wrote:
> >But as I see it, the real problem being solved by the new syntax
> >is that grep and map can exist solely as methods on some class
> >in the inheritance tree of @arrays, no global functions required.
> >That is a Good Thing.
> >
>
> In your op
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>
> We should bear in mind that Larry has had some health issues.
> And that he's currently unemployed with four children to support.
> Other matters are taking precedence at the moment.
Hmm... If the Larry and the Perl Foundation would be agreeable.
Damian Conway:
# > Brent Dax wrote:
# >> Incorrect.
# No. Your reading was correct. This is a rare case of Brent
# being mistaken.
Ack, sorry to both you and Buddha, and anyone else I inadvertently
confused. Well, at least I'm good enough for this to be considered a
"rare" case. :^)
--Brent Da
Damian Conway:
# What ~> and <~ do is to (respectively) allow arguments and
# invocants to appear in a different position to normal:
# arguments to the left of the subroutine/method name, and
# invocants to the right of the method's argument list.
#
# So, for subroutine arguments, these are exa
We should bear in mind that Larry has had some health issues.
And that he's currently unemployed with four children to support.
Other matters are taking precedence at the moment.
Hmm... If the Larry and the Perl Foundation would be agreeable. I'd just as
soon see a grant set up for Larry again t
Brent Dax asked:
So
@a ~> grep { ... } ~> @b
Is the same as
@b = grep { ... } @a
Yes.
As in...
class Array {
...
method grep (Array $ary: Code $code) returns Array {
...
}
method grep (Code $code: Array $ary) returns Array {
...
}
}
No. As in:
sub grep
On Friday, January 17, 2003, at 02:17 PM, Joseph F. Ryan wrote:
Mark J. Reed wrote:
On 2003-01-17 at 19:00:04, Simon Cozens wrote:
This is plainly untrue. See the "perlsub" documentation, which talks
about
"creating your own syntax" with the & prototype. You can do all this
in
Perl 5, and it
On Fri, Jan 17, 2003 at 03:10:48PM -0800, Damian Conway wrote:
> It's my understanding that TPF is not intending to offer Larry (or Dan)
> another grant for 2003. They feel that too many people have come to see
> TPF's role and contribution to have been limited to Perl 6 (though
> funding Dan was
Paul Johnson wrote:
Well, I'll be pretty interested to discover what cause is deemed more
deserving than Larry, Perl 6 or Parrot. The P still stands for Perl,
right?
True. But I suspect that TPF's position is that, to many people, Perl 6 is
far less important than mod_Perl, or DBI, or HTML::Ma
On Fri, Jan 17, 2003 at 04:21:08PM -0800, Damian Conway wrote:
> True. But I suspect that TPF's position is that, to many people, Perl 6 is
> far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or PDL,
> or Inline, or SpamAssassin, or XML::Parser, or YAML, or the Slashcode, or
> an
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> No. I said it was _special_, not _impossible_.
You said in Perl 5 it was X instead of Y. But it turned out to be Y
after all.
--
"He was a modest, good-humored boy. It was Oxford that made him insufferable."
[EMAIL PROTECTED] (Michael Lazzaro) writes:
> I don't think any aspect
> of this discussion is hinged on people being 'ignorant' of perl5
> behaviors,
Oh, I do, and you've dismissed that argument out of hand. This isn't
name-calling; this is a plea for Perl 6 not to become a language designed
by a
[EMAIL PROTECTED] (Damian Conway) writes:
> True. But I suspect that TPF's position is that, to many people, Perl 6 is
> far less important than mod_Perl, or DBI, or HTML::Mason, or POE, or
> PDL, or Inline, or SpamAssassin, or XML::Parser, or YAML, or the
> Slashcode, or any of a hundred other pro
[EMAIL PROTECTED] (Paul Johnson) writes:
> That may well be true, but it seems to me that if people's jobs depend
> on those projects then there is (or could be or should be) a source of
> funding available, should such be required, namely the companies who are
> (hopefully) making a profit on the
Simon Cozens wrote:
This isn't name-calling; this is a plea for Perl 6 not to become a language
> designed by a committee of ignorant amateurs.
Fortunately there is absolutely no chance of that.
Perl 6 is a language being designed by exactly one person.
And he's neither ignorant, nor an amateur
On Sat, Jan 18, 2003 at 02:11:37AM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Paul Johnson) writes:
> > That may well be true, but it seems to me that if people's jobs depend
> > on those projects then there is (or could be or should be) a source of
> > funding available, should such be requi
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 C syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the comma to
separate it f
Hey folks -
In my wanders through the parrot/languages subdirectories, it appears that
most example languages implement a complete compiler (ie lexxer -> parser
-> optimizer -> code emitter), which seems to be somewhat of a
duplication of labour. Has or is anyone worked on a framework a la gcc
w
Michael Lazzaro wrote:
If the usual syntax for a 2-arg subroutine call is:
foo A, B; # (1)
and the preferred perl5 C syntax is:
map {...} @a; # (2)
Then (2) is not grammatically following the same rule as (1). It works
because there is a rule that says the {...} doesn't need the
Michael Lazzaro wrote:
Great -- then I have only one more question, I think. In the words of a
certain cartoon character, what's *this* button do?
my $b is $a;
Syntax error, I'd expect. Though the desired effect could probably be achieved
with the C meta-property:
my $b is prop($a);
D
Jonathan Scott Duff wrote:
> will this:
my $a $b;
be illegal?
I certainly hope so!
Damian
Piers Cawley observed:
BTW, C is just sick!
(i.e. I'll *definitely* be using it ;-)
Surely anyone who does C<< my Array @foo >>, or C<< my Scalar $foo >>
will be using it, albeit indirectly.
Of course, but without the brain-twisting effect of the
repeated classname.
;-)
Damian
Yes, languages should now use IMCC as their target. Basically, they
generate IMCC instructions without regards for optimization and such so that
only a lexer/parser is needed. Take a look at the bf and ook languages for
an example. I think perl6 is also heading there.
Tanton
- Original Mess
90 matches
Mail list logo
