Re: Ada 2005?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 23 Dec 2004 13:09:34 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 22 Dec 2004 13:02:26 -0500, jayessay wrote:
>> 
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>> 
>>>>>> I doubt that CLOS seriously approaches the problem.
>>>>> 
>>>>> That's an odd statement, and it is just uninformed opinion which
>>>>> happens to be factually incorrect.
>>>> 
>>>> Maybe
>>> 
>>> There is no "maybe" about it.  You clearly have not studied this and
>>> therefore any comment you make on it is indeed uninformed opinion.
>>> 
>>>> , but the very first page introduces "no-applicable-method". It is a
>>>> non-starter for me. In my view the goal of safe MD design is to make
>>>> dispatch failures impossible (checked at compile time).
>>> 
>>> For true MD, that requires solving the halting problem in any Turing
>>> complete setting.
>> 
>> What about any proof?
> 
> One Hint: I/O.  There are many others.

You should define MD in a way which would not involve the Great Theory of
All, otherwise anything would become unsolvable...

>> [ Hint: Ada is statically typed, freezing rules do
>> not allow dynamic declaration of primitive operations. ]
> 
> Irrelevant to the above point.
> 
> However, these rules really have nothing to do with restricting
> "dynamic declarations" (Ada is static and so of course there are no
> dynamic declarations at all).

This is wrong. Not all dynamic declarations are of primitive operations.
Ada is a statically *typed* language.

> The rules are about where the
> representation of the entity is frozen and can no longer be added to
> even statically.  One consequence of these rules is that they remove a
> lot of the potential good from the separation of name space and class
> constructs.

I do not know what you mean here... 

>>> Good luck on your hopeless quest.  OTOH, if you
>>> restrict things enough, what you are talking about is simply
>>> overloading.  Ada already has that.
>> 
>> There is no way to restrict dynamic dispatch to make overloading of it.
>> Care to elaborate?
> 
> "things" /= DD

Are we talking about DD or "things"?

>>>> BTW, I am deeply unsatisfied with Ada's "MD" raising run-time
>>>> exceptions. It is tolerable because there was no better way, and
>>>> only as an intermediate state to be replaced by a "right" MD in the
>>>> future.
>>> 
>>> First, raising runtime exceptions is not only reasonable, it is the
>>> only thing possible in non trivial situations.
>> 
>> Again, the goal of proper design is to have no such situations.
> 
> Then you should not have dynamic dispatch at all.

Where that follows from?

>> Dispatch tables are finite in presence of finite number of types and
>> finite number of actual parameters. It is quite trivial to check
>> that all cells in each table are defined.
> 
> That's completely irrelevant to the problem.  The issue is whether any
> given actual call will find a match in the table.  The tables are
> trivial, it is the flow analysis that is (in the general case)
> impossible.

We have different general cases. Ada is not a dynamically typed language.
The reason for that was: not to have your "general case". Back to Ada's
case, it is trivial to find a match. Moreover it requires bounded time.
Otherwise, I guess polymorphic calls would never be adopted in Ada. The
problems with implementation of MD in Ada lie elsewhere.

>>> Second, Ada has no MD. That is a fact.
>> 
>> MD = "more to have than one dispatching parameter".
>> 
>> So clearly, Ada has MD.
> 
> Ah, so you define it away.  MD = "Multiple Dispatch" in the orignal
> context of this thread which is /= more than one dispatching
> parameter.  This should be obvious.  Ada does not have MD, to argue
> otherwise just makes you look silly.

Care to give another definition of MD?

>> To have any meta language is a wrong idea anyway.
> 
> MOP is not a meta language, it is a meta _protocol_ for object models.
> The only extent example (that I am aware of) is CLOS, but there could
> be others.
> 
> OTOH, I'm not sure why a "meta language" is somehow an intrinsically
> "wrong idea".

Because it is difficult to talk two languages for a person who is not
"above average" or else does not suffer from split personality...

>>> I've seen situations where this claim is completely at odds with
>>> reality.  Hence, your position would remove expressivity and force
>>> programmers into pounding square pegs into round holes.
>> 
>> Yes, this is exactly Ada's way (tm). Moreover, both pegs and the plate are
>> made of hard steel. So the programmer will spend a lot of time pounding on.
>> This has an important educational effect. Maybe next time [s]he will think
>> first.
> 
> I don't think this is "Ada's way".  I sure hope it isn't because it is
> the dumbest thing anyone could advocate.  The "education" any
> intelligent person would get from this would be, "this language is an
> extremely poor means for expressing elegant correct solutions."

An *intelligent* person would notice difference in shapes. The level of
intelligence is inversely proportional to the time spent on pounding...

>>> What you call "playing with fire", is simply another tool, with a well
>>> defined and specified protocol.  Can it be abused?  Yes.  Does it
>>> require someone above average to use it properly?  Most likely.  Can
>>> it be exactly the right thing for an elegant solution to a thorny
>>> problem?  Yes.
>> 
>> Bottom line:
>> *rejected*
> 
> Bottom line: You will not be able to solve a large class of (non
> trivial) problems as they will require far too much work to find a
> means to express their solution.

Which quote "would require someone above average to use it properly". How
much above?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de