What is Expressiveness in a Computer Language

[Duane Rettig]

"Marshall" <marshall.spight at gmail.com> writes:

> Pascal Costanza wrote:
>> Marshall wrote:
>> > Pascal Costanza wrote:
>> >> Consider a simple expression like 'a + b': In a dynamically typed
>> >> language, all I need to have in mind is that the program will attempt to
>> >> add two numbers. In a statically typed language, I additionally need to
>> >> know that there must a guarantee that a and b will always hold numbers.
>> >
>> > I still don't really see the difference.
>> >
>> > I would not expect that the dynamic programmer will be
>> > thinking that this code will have two numbers most of the
>> > time but sometimes not, and fail. I would expect that in both
>> > static and dynamic, the thought is that that code is adding
>> > two numbers, with the difference being the static context
>> > gives one a proof that this is so.
>>
>> There is a third option: it may be that at the point where I am writing
>> this code, I simply don't bother yet whether a and b will always be
>> numbers. In case something other than numbers pop up, I can then
>> make a decision how to proceed from there.
>
> Ouch; I have a really hard time understanding this.
>
> I can't see how you'd call + on a and b if you think they might
> not be numbers. If they could be something other than numbers,
> and you're treating them as if they are, is that sort of like
> doing a case analysis and only filling in one of the cases?
> If so, wouldn't you want to record that fact somehow?

But suppose + were polymorphic and someone (dynamically) added a
method on + to handle strings?  If the type error were that a and b
happened to be strings, there would be at least two courses of action
in the development of the program: limit a and b so that they are
never strings at this point, or define a method on + to add correct
functionality for the + operator.  Note that I use the term "correct",
because the correctness of the subprogram (including any added methods
on +) depends both on the correctness of usage within the language,
and also correctness of extensibilities allowed by the language for
the purpose of satisfying goals of the program.  In the many cases
where the eventual goals of the program are not known at the beginning
of the design, this extensibility is a good thing to have.

Note that the above paragraph explicitly leaves out Common Lisp,
because + is not extensible in CL.  CL does, however, allow for methods
to be defined on functions not already defined by the standard, so
the argument could still apply to some generic function named my-+,
or even on my-package::+ where the CL defined + operator is shadowed.

-- 
Duane Rettig    duane at franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182