On 10/7/05, chromatic <[EMAIL PROTECTED]> wrote:
> 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).
>
> 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.
That's easy. Define coerce:<as> (Int --> Array) {...}. Don't define
it after CHECK is run.
> > 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.)
That's what this thread is about. We're trying to nail down the
semantics so we know exactly how soft to be when an unannotating
programmer imports an annotated module.
> 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
> possible.
Of course. To me, those seems like flags of the compilation (or
running, since most of the time compilation will not be a separate
phase). The only person who gets to specify those is the person who
writes main.pl, because he has access to the #! line.
> 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.
Once you start diving into the guts of another module, you should be
prepared to start telling the compiler that it's wrong. I'm certainly
not saying that you shouldn't be able to do that.
> 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.
Okay. Some people find type annotations to be more useful than you do
though. If you want to argue that Perl shouldn't have type
annotations, go ahead. But for the moment, we're under the assumption
that Perl has the ability to make type annotations, and that those
annotations should have some affect on your program. And this thread
is trying to decide what that effect is.
Luke
