Re: Ada 2005?

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

On 27 Dec 2004 12:09:03 -0500, jayessay wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On 23 Dec 2004 13:09:34 -0500, jayessay wrote:
>>>>> 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...
> 
> Your comment is irrelevant on a number of counts.  I/O is hardly the
> "Great Theory of All", it is simply a part of the real world.  As
> another hint: classwide parameters.

If you have no definition, then there is nothing to discuss.

>>> 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.
> 
> So where can you _declare_ a new entity at runtime?

See ARM 3.1.

>> Not all dynamic declarations are of primitive operations.
>> Ada is a statically *typed* language.
> 
> Yeah.  So?

So dispatching is not equivalent to halting problem.

>>> 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".
> 
> The general case is simply one where you cannot determine at compile
> time things like uninitialized variables,

Class-wide variables cannot be left uninitialized.

> the specific type of a class
> wide variable at any given point in time, etc.

Present us any example of (but not one classified as a bounded error).

>> 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.
> 
> MD is irrelevant to to this point, which is the need for runtime
> exceptions.

So it has nothing to do with halting problem? Fine. Then what's the point?

> Ada has these and you can easily get them with it's
> polymorphic calls (which cannot be MD), i.e., Constraint_Error can be
> raised.  What's more, some of these constraint errors are _exactly_
> the equivalent of "method not found"

Nope, in Ada it is the equivalent of "method is final and defined to raise
Constraint_Error". It is a fundamentally different case.

>>>>> 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?
> 
> No, the original, as I noted here was and is the one under discussion
> and it is quite proper.

OK, I'll make it easier for you:

MD /= number of controlling parameters > 1 <=>
1) Exists MD with 1 or 0 controlling parameters; or
2) Dispatching subroutine with n>1 controlling parameters is not MD, but
SD, not D.

Go on!

>>>>> 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 thinkfirst.
>>> 
>>> 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 point is an elegant solution cannot be expressed cleanly without
> recourse to pounding because the language lacks the proper
> expressivity.

or that the person lacks some vital knowledge about software design...

> An intelligent person will notice and be annoyed that
> they are being required by the tool to pound away and/or to abandon
> their solution for a lesser one.

How do you compare solutions? Any metric?

> Which leads to, 
> 
>> The level of intelligence is inversely proportional to the time
>> spent on pounding...
> 
> Yes.  This means that in this case, intelligent people will _abandon_
> the tool (in this case the language) so that the elegant correct
> solution can be expressed without pounding.

Then you are in a wrong group. It seems that people in c.l.a are pretty
unintelligent to keep on using Ada, or maybe, there must be something wrong
with your theory...

>>>>> 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?
> 
> The question you pose is (mis)leading and pretty irrelevant.

I like irrelevant questions so much...

> A
> slightly better question would be "how many such people do you need?"
> Answer: enough.  This is not a facetious answer as the requirements
> will vary from project to project, but typically you will not need
> more than a few.

Refraining from yet another irrelevant question, I immediately deduce that
"few" = "enough".

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