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 < 1K Download

--Dks

--
dsto...@dstorrs.com

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

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. :)

signature.asc < 1K Download

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

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

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

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

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

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

--
  cognominal stef