[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Weirdness in Dylan spec
- To: Steve Strassmann <email@example.com.COM>
- Subject: Re: Weirdness in Dylan spec
- From: firstname.lastname@example.org
- Date: Tue, 07 Jul 92 16:22:24 -0700
- Cc: email@example.com.COM, firstname.lastname@example.org.COM
- In-reply-to: Your message of "Tue, 07 Jul 92 18:45:59 CDT." <9207072238.AA01580@cambridge.apple.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
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.