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

Reply via email to