Blocks, continuations and eval()

11 views
Skip to first unread message

Wolverian

unread,
Apr 8, 2005, 10:03:11 AM4/8/05
to perl6-l...@perl.org
Hi,

(I'm sorry if this topic has already been discussed.)

one day a friend asked if Perl 5 had a REPL facility.
(Read-Eval-Print-Loop). I told him it has perl -de0, which is different
in that it does not preserve the lexical scope across evaluated lines.
This is because eval STRING creates its own scope, in which the string
is then evaluated.

You can hack around this with a recursive eval(), which will eventually
blow the stack. I wrote a short module to do this, but never released
it. Have others done this? :)

To get to the real topic:

In Perl 6, the generic solution to fix this (if one wants to fix it)
seems, to me, to be to add a .eval method to objects that represent
scopes. I'm not sure if scopes are first class values in Perl 6. Are
they? How do you get the current scope as an object? Are scopes just
Code objects?

On #perl6, theorbtwo wasn't sure if .eval should be a method on coderefs
or blocks. Is there a difference between the two? I always hated this
about Ruby; there seems to be no practical value to the separation.

Also, are blocks/coderefs/scopes continuations? Should .eval be a method
in Continuation?

Thanks,

--
wolverian

signature.asc

David Storrs

unread,
Apr 8, 2005, 11:35:30 AM4/8/05
to perl6-l...@perl.org
On Fri, Apr 08, 2005 at 05:03:11PM +0300, wolverian wrote:

Hi wolverian,

> one day a friend asked if Perl 5 had a REPL facility.
> (Read-Eval-Print-Loop). I told him it has perl -de0, which is different

> [...]


> In Perl 6, the generic solution to fix this (if one wants to fix it)
> seems, to me, to be to add a .eval method to objects that represent
> scopes. I'm not sure if scopes are first class values in Perl 6. Are
> they? How do you get the current scope as an object? Are scopes just
> Code objects?

I'm unclear on what you're looking for. Are you trying to get a way
to do interactive coding in P6? Or the ability to "freeze" a scope
and execute it later? Or something else?

--Dks


--
dst...@dstorrs.com

MrJoltCola

unread,
Apr 8, 2005, 12:18:45 PM4/8/05
to wolverian, perl6-l...@perl.org
At 10:03 AM 4/8/2005, wolverian wrote:
>To get to the real topic:
>
>In Perl 6, the generic solution to fix this (if one wants to fix it)
>seems, to me, to be to add a .eval method to objects that represent
>scopes. I'm not sure if scopes are first class values in Perl 6. Are
>they? How do you get the current scope as an object? Are scopes just
>Code objects?
>
>On #perl6, theorbtwo wasn't sure if .eval should be a method on coderefs
>or blocks. Is there a difference between the two? I always hated this
>about Ruby; there seems to be no practical value to the separation.
>
>Also, are blocks/coderefs/scopes continuations? Should .eval be a method
>in Continuation?

I'm having a bit of trouble following you, but I can tell you that the VM
portion
treats continuations as well as lexical scopes or pads as first class Parrot
objects (or PMCs).

I cannot say how much Perl6 will expose to the high level language.

Can you tell me what your idea of a "scope" is? I'm thinking a
continuation, and if that is what you are thinking, I'm thinking the
answer to your question is yes.

-Melvin


Wolverian

unread,
Apr 8, 2005, 12:00:40 PM4/8/05
to perl6-l...@perl.org
On Fri, Apr 08, 2005 at 08:35:30AM -0700, David Storrs wrote:
> I'm unclear on what you're looking for. Are you trying to get a way
> to do interactive coding in P6? Or the ability to "freeze" a scope
> and execute it later? Or something else?

Neither in itself. I'm looking for a way to refer to scopes
programmatically. I'm also asking if they are continuations, or blocks,
or coderefs, or are those all the same?

The two things you mention are effects of being able to refer to scopes
in such a fashion. I do want both, but the real question isn't if they
are possible, but about what blocks, coderefs and scopes are.

I'm sorry if I was unclear. I probably should have spent more time
writing the post. :)

> --Dks

--
wolverian

signature.asc

Wolverian

unread,
Apr 8, 2005, 12:41:40 PM4/8/05
to perl6-l...@perl.org
On Fri, Apr 08, 2005 at 12:18:45PM -0400, MrJoltCola wrote:
> I cannot say how much Perl6 will expose to the high level language.

That is what I'm wondering about. I'm sorry I was so unclear.

> Can you tell me what your idea of a "scope" is? I'm thinking a
> continuation, and if that is what you are thinking, I'm thinking the
> answer to your question is yes.

Yes. I want to know how Perl 6 exposes continuations, and how to get one
for, say, the current lexical scope, and if it has a method on it that
lets me evaluate code in that context (or some other way to do that).

> -Melvin

--
wolverian

signature.asc

Piers Cawley

unread,
Apr 12, 2005, 6:36:02 AM4/12/05
to perl6-l...@perl.org
wolverian <wo...@sci.fi> writes:

As I understand what Larry's said before. Out of the box, it
doesn't. Apparently we're going to have to descend to Parrot to write
evalcc/letcc/your-preferred-continuation-idiom equivalent.

Larry Wall

unread,
Apr 12, 2005, 7:17:56 AM4/12/05
to perl6-l...@perl.org

We'll make continuations available in Perl for people who ask for
them specially, but we're not going to leave them sitting out in the
open where some poor benighted pilgrim might trip over them unawares.

Larry

Piers Cawley

unread,
Apr 12, 2005, 1:35:19 PM4/12/05
to perl6-l...@perl.org
Larry Wall <la...@wall.org> writes:

Oh goody! Presumably we're initially talking of a simple
'call_with_current_continuation'?

Wolverian

unread,
Apr 21, 2005, 9:30:07 AM4/21/05
to perl6-l...@perl.org
On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote:
> We'll make continuations available in Perl for people who ask for
> them specially, but we're not going to leave them sitting out in the
> open where some poor benighted pilgrim might trip over them unawares.

Sorry for replying so late, but I missed your reply somehow. I just want
to ask a little clarification on this; exactly what kind of hiding are
you considering for continuations? That is, do you just mean that there
will not be a 'call/cc' primitive by default in the global namespace?
I'm fine with that, as that's just one method of capturing the calling
continuation.

> Larry

--
wolverian

signature.asc

Larry Wall

unread,
Apr 21, 2005, 11:36:28 AM4/21/05
to perl6-l...@perl.org
On Thu, Apr 21, 2005 at 04:30:07PM +0300, wolverian wrote:

I suspect it's just something like

use Continuations;

at the top to enable the low-level interface. There would be no
restriction on using continuation semantics provided by other modules,
because then the "use" of that other module implies whatever form
of continuation it provides.

My concern is primarily the reader of the code, who needs some kind
of warning that one can get sliced while juggling sharp knives. If
we were willing to be a little more Ada-like, we'd make it a shouted
warning:

use CONTINUATIONS;

Hmm, maybe that's not such a bad policy. I wonder what other "dangerous"
modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance.

Larry

Nigel Sandever

unread,
Apr 21, 2005, 12:09:21 PM4/21/05
to perl6-l...@perl.org
On Thu, 21 Apr 2005 08:36:28 -0700, la...@wall.org (Larry Wall) wrote:
>
> Hmm, maybe that's not such a bad policy. I wonder what other "dangerous"
> modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance.
>

How about
use RE_EVAL; # or should that be REALLY_EVIL?

> Larry

Stéphane Payrard

unread,
Apr 22, 2005, 7:15:35 AM4/22/05
to perl6-l...@perl.org
Hi,

I am making a presentation about Perl6 this week end. My point will
be: the next generation of applicative languages will be scripting
languages because they have come of age.

Alternatives don't cut it anymore. Indeed C and C++ are memory
allocation nightmare; Java and C# don't have read-eval loop, a
necessary condition for rapid learning and development. Functional
languages like haskell or ocaml are very powerful but needs massive
wetware reconfiguration to get used to the syntax and semantic.

So I will make do a presentation of Perl6 and Parrot features to make
my point about upcoming scripting languages.

I have a few questions inspired by my recently acquired knowledge
about functional languages. Perl6 being the ultimate syncretist
language, I wonder if some functional features will make it
into Perl6. I know we already got currying.

A very nice feature of Haskell and *ml is the possibility to define
complex datastructures types and the control flow that manipulate
these structures: constructors and pattern matching. With these
languages, in a very deep sense, control flow is pattern matching. Can
we expect Perl6 to propose something similar?

If yes, could be the matching part folded into the rule syntax? Rules
are about identifying "structures" in parsed strings and acting
accordingly. Partern matching is about identify typed structures and
acting accordingly. There is a similarity there. Also we may want to
match both at the structural level and at the string level. Or is
this asking too much of rules, that have already swallowed both lexing
and parsing.

The notion of data type become very useful in Perl6 for people who
want it. In fact, Perl6 is a mix of dynamic and static types
(bindings). I think type theory handles type inference in this kind
of langage with something called dependant type. Though I have to go
thru ATTaPl to get it.

Perl, like many scripting language is very lax and, when needed,
converts implicitely values within expressions. This is nice, but I
think that makes type inference impossible. Type inference is good
because it allows to generate very efficient/strict code with very
little type annotations.

Can we expect in a distance feature a pragmatic mode convention to
control automatic type conversions if any and the type inference
scheme chosen when/if implemented?


--
cognominal stef

Larry Wall

unread,
Apr 22, 2005, 12:32:55 PM4/22/05
to perl6-l...@perl.org, st...@payrard.net
On Fri, Apr 22, 2005 at 01:15:35PM +0200, Stéphane Payrard wrote:
: Hi,

:
: I am making a presentation about Perl6 this week end. My point will
: be: the next generation of applicative languages will be scripting
: languages because they have come of age.
:
: Alternatives don't cut it anymore. Indeed C and C++ are memory
: allocation nightmare; Java and C# don't have read-eval loop, a
: necessary condition for rapid learning and development. Functional
: languages like haskell or ocaml are very powerful but needs massive
: wetware reconfiguration to get used to the syntax and semantic.
:
: So I will make do a presentation of Perl6 and Parrot features to make
: my point about upcoming scripting languages.
:
: I have a few questions inspired by my recently acquired knowledge
: about functional languages. Perl6 being the ultimate syncretist
: language, I wonder if some functional features will make it
: into Perl6. I know we already got currying.

A lot of features are making it into Perl 6 that have historically been
associated with "functional" programming. Off the top of my head:

currying
continuations
tail recursion
laziness
autogenerating arrays
[] pattern matching arguments

: A very nice feature of Haskell and *ml is the possibility to define


: complex datastructures types and the control flow that manipulate
: these structures: constructors and pattern matching. With these
: languages, in a very deep sense, control flow is pattern matching. Can
: we expect Perl6 to propose something similar?

We don't (yet) have a full unification engine, though Luke has thought
about that some. But it probably wouldn't be the default in any case.
MMD and [] matching is about as much as normal people can take in.
And of course, we let people derive from the Perl grammar itself, and
define macros based on parse rules, which is at least compile-time
pattern matching. (Though we discourage use of backtracking parsers
for dwimmery; the standard Perl parser will use backtracking only to
produce more meaningful error messages.)

: If yes, could be the matching part folded into the rule syntax? Rules


: are about identifying "structures" in parsed strings and acting
: accordingly. Partern matching is about identify typed structures and
: acting accordingly. There is a similarity there. Also we may want to
: match both at the structural level and at the string level. Or is
: this asking too much of rules, that have already swallowed both lexing
: and parsing.

Perl 6 rules are a new language, and that language can be extended
in various ways. Structural matching is one of those things that,
while we aren't worrying about getting it into Standard Perl 6,
we want to make sure it's possible to extend the mechanism in that
direction. Though we've already said that you can match against
an array, and recognize element boundaries with <,>, so we're most
of the way there by some reckoning. If the matcher is cognizent
of array element boundaries, it's also cognizant of array elements,
and a subrule could presumably be taught to dive down into one of
those elements.

: The notion of data type become very useful in Perl6 for people who


: want it. In fact, Perl6 is a mix of dynamic and static types
: (bindings). I think type theory handles type inference in this kind
: of langage with something called dependant type. Though I have to go
: thru ATTaPl to get it.

I'm not famaliar with that usage, but then, I haven't studied type
inferencing in any kind of depth.

: Perl, like many scripting language is very lax and, when needed,


: converts implicitely values within expressions. This is nice, but I
: think that makes type inference impossible. Type inference is good
: because it allows to generate very efficient/strict code with very
: little type annotations.

Well, we hope to get some of those benefits from our optional type system.

: Can we expect in a distance feature a pragmatic mode convention to


: control automatic type conversions if any and the type inference
: scheme chosen when/if implemented?

If we design things right, I don't see how we can prevent it. :-)

My only requirement is that each file starts at the top in Standard
Perl and mutates into your language of choice by explicit lexically
scoped declaration.

Hmm, when you said "pragmatic modes", it occurred to me that I would
have difficulty calling "use ML" a mere pragma, since pragmas are
supposed to be about pragmatics, not syntax or semantics. I suppose
if we wanted to ignore Greek entirely we could call a syntax mutator
a synta and a semantics mutator a semanta, though of course these
categories shade into each other, and something like "use Python"
is going to have issues at all three levels. I don't know how much
benefit there is to trying to keep these linguistic levels straight,
except that we should probably reserve the actual language names
for complete emulation, and use names like "Javalike" or "Lispish"
for lesser mutations.

But anyway, the historic usage of "pragma" in CS is for hints to the
compiler that don't actually affect the meaning of the program, just
its implementation. It's almost certainly my fault, but I think the
Perl community as a whole has taken the term in a different direction,
and I'm not sure that we're making a meaningful distinction with
it anymore, other than to mean that a module name happens to be
spelled with a lowercase letter. I regret the loss of a good word,
and wonder if there's any way to also repair that damage, as long as
we're scheduling a revolution. Maybe it doesn't matter.

Larry

Stéphane Payrard

unread,
Apr 22, 2005, 2:13:58 PM4/22/05
to perl6-l...@perl.org, st...@payrard.net
On Fri, Apr 22, 2005 at 09:32:55AM -0700, Larry Wall wrote:

Thank you for your detailled answer. I still don't get what you mean
by "[] pattern matching arguments".
Do you mean smart pattern matching on composite values?

>
> A lot of features are making it into Perl 6 that have historically been
> associated with "functional" programming. Off the top of my head:

> ...
> [] pattern matching arguments

--
cognominal stef

Stéphane Payrard

unread,
Apr 22, 2005, 4:53:50 PM4/22/05
to perl6-l...@perl.org, st...@payrard.net

Thx to people on #perl6, I got it. It is a form of pattern matching
on arguments. It is described in S06 in under the headers "Unpacking
hash parameters", "Unpacking array parameters".

sub quicksort ([$pivot, *@data], ?$reverse, ?$inplace) {
...
}

So if we mix that with typing, we will end with full fledged unification?

--
cognominal stef

Reply all
Reply to author
Forward
0 new messages