Re: Ada syntax questions

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

On 2020-12-24 05:06, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:rrv0u2$102i$1@gioia.aioe.org...
>> On 2020-12-23 02:23, Randy Brukardt wrote:
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>>> news:rrs92d$1pfi$1@gioia.aioe.org...
>>> ...
>>>> But you cannot rid of X(...) syntax, where X is an object.
>>>
>>> That's a prefixed view, of course. No one would want to get rid of that.
>>
>> Hmm, where is the operation? A prefixed view is
>>
>>     <expression>.<operation>(...)
>>
>> Indexing is
>>
>>     <expression>(...)
> 
> I neglected to mention that what Ada calls objects are also function calls
> in this proposed generalization.

Well, you must stop the recursion somewhere. It is fine to treat access 
to objects as calls, e.g. to getter/setter, or to indexation, or to 
dereferencing, but you must finish at some point with something spelled 
as a call to a subprogram. In the case of a subprogram call you are 
already there. With "objects" you need a few hops to get there.

  (Much like enumeration literals are in
> Ada.) So for static semantics (that is, compile-time), pretty much
> everything is a function call. This gets rid of the anomalies associated
> with constants (which don't overload and thus hide more than a parameterless
> function - which is otherwise the same thing); combined with
> variable-returning functions, everything is overloadable and treated the
> same in expressions. Almost no special cases (operators still require some
> special casing, but we can make them always visible which would eliminate
> more issues).

Yes, resolving overloading/hiding issues in a uniform way must help.

> Clearly a compiler for this language (which can't be Ada, unfortunately, way
> too incompatible) would special-case some kinds of built-in functions for
> things like objects and indexing. But that doesn't need to hair up the
> semantic model, just the implementations.
> 
> ...
>>> Ada (and most other languages) are full of redundant stuff. Simpilfy the
>>> basics and then one has more room for interesting stuff (static analysis,
>>> parallel execution, etc.).
>>
>> Yes, but I would rather keep all this stuff in the language making it
>> overridable primitive operations.
> 
> Yeah, you don't plan to formally describe nor implement this language, so
> you don't really care about how complex it gets. :-) Well, at least not
> until performance suffers.

Well, if that becomes a part of a library, why should I care?

I would definitely get of generics, and clarify overloading in some way.

> Ada is reaching the limit of what can be done
> without substantial incompatibility. If we're going to allow that, we need
> to start with a cleaner base, and part of that is getting rid of
> redundancies.

We see that differently. So far new features were added on top which 
naturally leads to the mess we observe. The problem is lack of 
generalization not inconsistency. If the new Ada cannot express the old 
messy, but consistent Ada, then this new Ada is not general enough and 
it will arrive at the same amount of mess sooner or later.

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