Re: $RS paragraph mode going away?

[Rafael Garcia-Suarez]

Larry Wall wrote :
> 
> Paragraph mode is not going away--it's merely going elsewhere.  :-)
> 
>: If so, what's the rationale?  Another case of "you can't do it right
>: internationally, so better not to do it at all"?
> 
> No, it's simply that using a global variable to control something
> that should be a filehandle attribute is the wrong way to go about it.

The readline function takes an input filehandle and a line separator and
returns a line. So it makes sense to store the line separator in the
filehandle. OK.

>: I'm just looking at the huge number of stanza-based files and
>: system-utility output sysadmins deal with every day using C<$/ = ''>, and
>: thinking "yeah, I could just write a grammar, but it's just a simple regex
>: match in paragraph mode..."
> 
> No problem, you'll just say something like:
> 
> $fh = open $filename, ":para";
> for <$fh> -> $para { ... }
> 
> Eventually the Perl 5 folks will get around to implementing such
> user-oriented layers in Perl 5, but at the moment they're still working
> on the encoding-oriented layers, which is fine.

This seems to be a weird way to specify the line separator.

What if you stack many of them ?
$fh = open $filename, ":para:slurp";
$fh = open $filename, ":slurp:para";
$fh = open $filename, ":para:chunk(8192)";
# (assumming that :chunk does the job of $/ = \8192)

or, worse, if you mix them with encoding layers ?
$fh = open $filename, ":lineending(\n):crlf";
$fh = open $filename, ":crlf:lineending(\n)"; # will I get \r chars ?

Encoding layers know nothing about end-of-line terminators. I'm under
the impression that encoding layers and user layers have different
semantics : respectively buffer filters and user-space modifiers.
(Another example of a user layer could be :taint to taint/untaint the
data read from the filehandle. That's something that modifies a
filehandle's attribute, but that doesn't affect the way the data is
read/written and encoded.)

Oh, and $\ should become a filehandle attribute too.
$fh = open $filename, ">:lineending(\n)";
$fh = open $filename, ">:lineending(\n):gzip";
$fh = open $filename, ">:gzip:lineending(\n)"; # ???

Re: Perl6 grammar (take IV)

[Trey Harris]

In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
> - Implicit currying variables ($^a etc) are in.  I thought I had read
>   somewhere they were gone in favor of closure args, but people seem
>   to be using them, and they're not hard to put in.

My understanding is that they still exist as placeholder variables, but
no longer implicitly curry.  I.e.,

{$^a + $^b}

is a synonym for

-> $a, $b {$a + $b}

Trey

Re: Perl 6 Summary

[Thom Boyer]

Peter Scott wrote:

> At 01:54 PM 7/3/02 -0600, Thom Boyer wrote:
>
>> I'm personally MUCH more interested in Python's generators
>> .
>>
>> A generator is like an iterator in that it can produce
>> a series of values. But unlike iterators, when you ask
>> a generator for the next value, it picks up execution
>> exactly where it left off when it returned the last
>> value -- including all [its] stack.
>
>
> Isn't that a coroutine?  I thought they were already slated for P6.  
> *Rummage*  Yes:
>
> http://www.yetanother.org/damian/diary_April_2001.html
> Or if you like:
> http://www.yetanother.org/damian/Perl5+i/coroutines.html
> -- 
> Peter Scott
> Pacific Systems Design Technologies

Yes, coroutines are more than enough to implement generators (as Dan 
Sugalski has already agreed).

And thanks for the pointers. I've been out of touch with the Perl 
community the last couple of years. It's been exciting seeing how Perl 6 
is shaping up, but I'm having a hard time making up lost time. The 
postings to perl6-language often take for granted features of Perl 6 
which I haven't been able to find in any of the apocalypses or exegeses, 
so I've been plowing through the archive trying to get more background 
-- but I hadn't yet made it back to April 2001!

Knowing that coroutines are already under discussion WRT Perl, I was 
able to google the existence of RFC 31 and other references to 
coroutines in Damian's corpus. (Including a slide show from August 2001 
titled "Perl 6 Prospectus", where it is in the "What we might see" 
section.) I've been unable to determine whether coroutines are really 
"slated for P6," as you suggest. Has there been any indication whether 
those suggestions have met with Larry's approval?

=thom

Re: Perl6 grammar (take IV)

[Larry Wall]

On Sat, 6 Jul 2002, Trey Harris wrote:
: In a message dated Sat, 6 Jul 2002, Sean O'Rourke writes:
: > - Implicit currying variables ($^a etc) are in.  I thought I had read
: >   somewhere they were gone in favor of closure args, but people seem
: >   to be using them, and they're not hard to put in.
: 
: My understanding is that they still exist as placeholder variables, but
: no longer implicitly curry.  I.e.,
: 
: {$^a + $^b}
: 
: is a synonym for
: 
: -> $a, $b {$a + $b}

That is correct.  Currying will be done via some explicit method.
Sentiment at yapc favored something resembling:

&incr := &add.assuming(x => 1);

Larry

Re: Perl 6 Summary

[Larry Wall]

On Sun, 7 Jul 2002, Thom Boyer wrote:
: Has there been any indication whether those suggestions have met
: with Larry's approval?

There will certainly be support for that sort of thing in Parrot,
up to and including continuations.  Otherwise we cannot hope to
host all these other languages.  Exactly how Perl will make the
interface known to its users is still up for grabs.  Hopefully we
can be specific enough that the compiler can figure out when it has
to use continuations and when it can use some lighter mechanism.

>From a language design point of view, we want fancy control structures
to just kind of sneak into people's consciences just as closures did in
Perl 5.  The capabilities should be there, but they should just work
the way you expect when you get to having any expectations whatsover.
It'd be really nice to find a way to explain continuations to people
without inflicting the typical torturous explanations on people who
aren't interested in brain pretzels.

Perhaps we should just explain continuations in terms of time travel.
Most people think they understand time travel, even when they don't.
A continuation is just a funny label for a point in time, and you have
a way of sending messages from the future back to that point in time.

Another way of looking at it is that a continuation is a hypothesis
about the future, and calling the continuation is a way of saying
"oops" about that hypothesis.

Basically, we need to find the right oversimplification to make people
think they understand it.  Kind of like cancelling the dx's and dy's
in calculus--the physics profs always tell you to do that, while
warning you not to tell the math profs they're telling you to do that,
because it doesn't always work, except in real life.

Larry