Re: Weirdness in Dylan spec

[nathan@akbar.teleos.com]

>The two versions of "ship" above are quite different, and I personally
>prefer to see them separated by a package or module boundary. 
>What happens when you call (ship sailor-sam seattle)? I don't think
>having subtly different arglists to different SHIP methods is enough 
>to keep the meaning of this code clear.
>
>So OK, there's some problems with CL packages, and we hope to address 
>those in Dylan with modules. I don't see why such a proliferation of 
>packages is necessary and/or bad. In general these conflicts will be 
>relatively rare, and when they arise they should be explicitly dealt
>with.

I agree with what you said about this example, but what about my
original issue.  Namely, is it broken for a 'dynamic'/interactive
language to *force* the user to forever (where forever is the duration
of the current process) commit a symbol to a particular use?

As the wording of this question implies, my opinion is a decisive No.
All the functionality of such a language should be accessible in a way
that is tolerant of user errors (e.g. typos) and users simply changing
their minds about the way the code is organized.

define-generic-function appears to be intolerant of such changes.  Is
this the case?  If so why?

Note that I say nothing about *allowing* the user to forever commit a
symbol, but this should be a special case for when the user is doing
optimization and trying to squeeze that last little bit of speed out
of the compiler, *not* the normal case.

My hope is that this is all pretty obvious, and this is just an error
in the spec.

Nathan Wilson
Teleos Research
nathan@teleos.com