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
