Re: What can be hyperoperated?
Note: I'm actually not talking about hyperoperators below, or
map/grep/sort. Just 'for'.
On Sat, 26 Jan 2002 12:32:06 -0600, Jonathan Scott Duff wrote:
> @result = for @a; @b -> $a; $b { $a op $b }
I'd like to chime in withthe people who have already said that the
semicolons are a bit confusing.
I'd like to propose a slightly different syntax. Is this maybe valid, or
have I missed a gaping problem?
# Simplest case: one data source, pulling elements one at a time,
# operating against a constant
@result = for @a -> ($a) { $a + 2 }
More formally, this would be:
for LIST -> LIST [[, LIST -> LIST]...] CLOSURE (returns: LIST)
So, you could write things like so:
# pull elements off two-by-two
for @a -> $x, $y { ... }
# flatten @a, @b together, pull elements off two-by-two
for @a, @b -> $x, $y { ... }
# pull one off @a, one off @b
for @a -> $x,
@b -> $y
{ ... }
# pull one off @a, two off @b
for @a -> $x,
@b -> $y, $z
{ ... }
Of course, all of these only DWIM if -> knows that it takes exactly one
item on the left, and a list on the right.
As an extra bit of magic, perhaps, when the only thing to the left of ->
is a scalar, it could reduce to this (in Perl5 terms):
# This Perl6:
for $_ -> $x { ... }
# is the same as this Perl5:
{
my $x = $_;
local ($_);
{ ... }
}
Dave Storrs
Re: Perl6::Tokeniser
begin quote from Rafael Garcia-Suarez:
> Out of curiosity, what kind of parser do you intend to write ? A
> Parse::RecDescent one ?
Parse::Yapp.
> Have you an idea about what will be the 'final'
> parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?)
Yep, LALR1, probably yacc generated.
> Side-note about whitespace. This is going to be tricky, because of the
> DWIMery involved by the end-of-line on some constructs (do{}, IIRC).
I know. This ought to be handled by '{' and '}', but it currently isn't.
> IMHO, Perl6::Tokener->toke() should not return whitespace to the parser
> (currently it returns (undef)x2, if I understand correctly), but should
> trigger some internal state change on \n (or whatever a end-of-line may
> be). So, it can insert a fake ';' token after "do { ... }\n" for the
> parser.
That's one way to do it, but I think it's probably easier to look ahead
after '}'.
--
A debugged program is one for which you have not yet found the conditions
that make it fail.
-- Jerry Ogdin
Re: Perl6::Tokeniser
Simon Cozens wrote in perl.perl6.language:
>
> An enhanced version of this (with documentation, no less) is available
> from CPAN. I'll be releasing updates to there. There are a few things
> I need to fix, but this should be enough to start sensible parser work,
> which I intend to in the near future.
Out of curiosity, what kind of parser do you intend to write ? A
Parse::RecDescent one ? Have you an idea about what will be the 'final'
parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?)
Side-note about whitespace. This is going to be tricky, because of the
DWIMery involved by the end-of-line on some constructs (do{}, IIRC).
IMHO, Perl6::Tokener->toke() should not return whitespace to the parser
(currently it returns (undef)x2, if I understand correctly), but should
trigger some internal state change on \n (or whatever a end-of-line may
be). So, it can insert a fake ';' token after "do { ... }\n" for the
parser.
--
Rafael Garcia-Suarez
Re: Perl6::Tokeniser
begin quote from Simon Cozens: > This is my new toy. It's not perfect. I know what's lacking and I know > how to fix it, but time is always against us. You don't need any > documentation, you're intelligent people. Feed some code to > Perl6::Tokeniser::toke, and it'll give you an array. An enhanced version of this (with documentation, no less) is available from CPAN. I'll be releasing updates to there. There are a few things I need to fix, but this should be enough to start sensible parser work, which I intend to in the near future. (Lots o' writing to do this week, unfortunately.) -- If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming
RE: Perl6 -- what is in a name?
From: Melvin Smith [mailto:[EMAIL PROTECTED]] > At 01:52 PM 1/28/2002 -0600, Garrett Goebel wrote: > >From: Brent Dax [mailto:[EMAIL PROTECTED]] > > > Aaron Sherman: > > > # > > > # I think the first guy that gets hired to maintain Perl6 code, > > > # and think "hey, I know Perl, no sweat" will disagree with > > > # you. > > > > > > I disagree. He'll see stuff he doesn't understand and try to > > > consult perldoc on it, at which point he'll realize that he's > > > working with Perl 6. Then he'll run out, get Camel IV, read > > > it, and go back to work. Programmer is working with a better > > > version of language, program is fixed, and ORA made fifty > > > bucks. Everybody's happy. :^) > > > >Perhaps. Or perhaps he'll be like our company's lead C++ > >developers. They liked Perl4 well enough for a certain problem > >domain, saw some Perl5 code... and have tried to stay away from > >it ever since. > > > >Perl6 isn't going to make everyone happy. > > I have a hard time believing those C++ guys are really Perl lovers; > I'ver never spoken to a Perl fan that didn't have dreams of a making > the language even better than it already is; better OO in Perl, etc. > Maybe they just have a huge unwieldy Perl4 app they don't > wish to port. They were C++ lovers not Perl lovers. Perl was just a tool in their chest. In their minds Perl4 was a simple elegant swiss army knife for data munging. Perl5 was a new version of the same tool, but with too many extra whiz bang features to suit their fancy. But hey, Bryan Warnock said it best: > >Perl6 isn't going to make everyone happy. > > That's right, it isn't. Nor should it strive to. This isn't Aesops fable about "The Miller, His Son, And Their Ass". http://www.literature.org/authors/aesop/fables/chapter-281.html
