develooper Front page | perl.perl6.language | Postings from March 2005

Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?

Thread Previous | Thread Next
From:
Luke Palmer
Date:
March 30, 2005 20:20
Subject:
Re: Parameter and trait questions - just how 'only' _is_ 'read-only'?
Message ID:
20050331042037.GA3878@navi.cx
Aaron Sherman writes:
> > Please think carefully about how dynamic you want Perl 6 to be....
> > > Dynamic is good, but there's such a thing as too much of a good thing.
> > 
> > We'd like Perl 6 to be as dynamic as Perl 5.
> 
> We'd think that is impossible. Perl 5 had full control of the
> run-time, Perl 6 does not. 

Like hell it doesn't.  Parrot is designed to support Perl 5.  

Perl 6 can do all the fancy stuff that Perl 5 did.  If the Perl 6
compiler runs in Parrot, then it can control Parrot as it compiles, and
reap information from that as it compiles.  Parrot can easily redefine
stuff on the fly and eval code at runtime.  I don't see what "full
control of the run-time" Perl 5 has that Perl 6 won't (if you have
something specific in mind, enlighten me please).

> What's more, Perl 6 introduces types, mmd, function signature
> overloading, operator overloading and a host of other features which,
> combined with the level of dynamism found in Perl 5 would seem to me
> to lead to a compiler which cannot assist the user in writing
> debuggable code.

You keep mentioning this thing "debuggable code" and saying that adding
dynamism impairs it.  I'd say that Perl 5 is debuggable; I can certainly
debug it.  The kinds of modules that I work on introduce types and mmd,
where Perl 5 already had operator overloading.  I don't understand how
adding dyanmism impairs debuggability[1].

The reason that types and MMD can be introduced into Perl 5 is because
it's so dynamic.  We, as language designers in 2005, can't possibly know
what will be to us as MMD is to perl 5, but we want module writers to be
able to implement it, whatever it is.

Sorry I'm getting so worked up here....  It's just that in designing the
next generation of a language that I cherish for its dynamism and
freedom, I don't like the idea of restricting that in the interest of...
whatever the interest is in (I can't actually tell with this argument).

I think what Perl 6 can offer us over Perl 5 in terms of "safety", on a
very feature-removed level, is much more comprehensive compile
information available to the program.  We could easily leave out the
static type system from Perl 6 (not that I actually want to do this),
and a module that implements it would be a heck of a lot easier to write
than a module that implements it in Perl 5.

Perl 6 gives you so many levels of control: lexical syntax control,
hooks for everything you can dream of, possibility of generating pure
parrot code inline, continuations (which help in writing a debugger),
that I can't fathom how this could less debuggable than Perl 5.  If you
want to see when something, anything at all, is happening, stick a
debugger hook in there.  The more "static" we make our language--the
less dynamic we allow it to be--the more debugging power we're taking
away from the programmer.  The lose of making things dynamic is that the
compiler can't make as many assumptions, but Perl 6 allows many ways to
tell it when it can make assumptions.  As chromatic said, the programmer
usually knows when the compiler can make assumptions better than the
compiler does anyway.

Whew...

Okay, how can I turn around my rant and make it say something
productive?  

I probably can't tonight.  Nice yelling at you. :-)

Luke

[1] It might in a traditional debugger, but we are free to write our
debugger in the extremely dynamic Perl 6, running it right alongside our
program with all of our introspection needs at hand.  If our debugger
isn't good enough, we have the tools to write a better one.  And for
people like me who don't use the perl debugger, but who prefer print
statements and Data::Dumper diagnostics, more dynamism implies more
debugging power, not less.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About