On Fri, 2005-10-07 at 17:43 -0600, Luke Palmer wrote:

> No, you can't overload assignment at runtime because you can't
> overload assigment at any time, so says the language spec (well, not
> any formal spec; so says Larry as far as I remember).

I'm wearing my "just a programmer, not a denizen of p6l" hat.  Pretend I
don't know the difference between overloading assignment and setting
special STORE magic and I want the option to be able to have Array do
something meaningful and significant to both of us when I assign a
constant scalar to it.

Again, I don't care *how* I accomplish it, as long as I don't have to
root around in the source code of Perl 6 itself to make it work.

> As for the first argument, presumably people put type annotations on
> their code so that we can do some reasoning and tell them about
> errors.

I don't want to use a module off of 6PAN that breaks my code because its
type annotations have leaked out into the rest of my code and I have no
idea what the compiler error messages mean.  It's sort of the anti-$&,
except it can make my program run faster.  (Correct answers: depends on
the question.  Wrong answers: instantaneous.)

It's up to the person who *runs* the code, not the person who writes a
component and can't possibly decide from now 'til forever exactly every
circumstance in which he will allow people to use the component, to
decide what level of compiler complexity and strictness to allow.  If my
program takes a second to run, I don't want to spend several seconds
performing type checks more suited for a long-running program.  If my
program's a network-bound server process that ought to share most of its
memory, maybe I don't want to JIT things.  If I'm running the final
customer tests before delivering frozen bytecode to customers who won't
be changing the code, maybe I want as many checks and optimizations as

Making the author of a module decide that is wrong.  Maybe allowing a
module author to request stricter typing within the module is fine, but
it oughtn't be the last word on the subject.

I've programmed in languages that froze certain library code at a
specific level of strictness for philosophical and speed-related
reasons.  It was painful when I needed to do something that the language
designers and library developers never thought I might need to do.
Sure, I have a "just a programmer" hat, but that doesn't mean I can't
use well-encapsulated magic when I really need it.

To make this concrete -- Java's final: broken, wrong, stupid.  Pick

Types are abstractions and all abstractions break sometimes.  Of the
possible analysis features the compiler can perform by default, I prefer
to enforce sensible symbol names, as-small-as-possible scopes, and lack
of near and exact duplication.  These to me are much more useful than an
optional-until-someone-somewhere-uses-it type system that prevents me
from finding the escape hatches purposely built into the language.

-- c

Reply via email to