Re: The Language I want
- From: ardjussi <jussi.santti@xxxxxx>
- Date: Wed, 11 Mar 2009 05:42:13 -0700 (PDT)
On 8 maalis, 20:16, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:
On Sun, 8 Mar 2009 15:51:10 -0000, Aaron Gray wrote:
"Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx> wrote in message
news:lr4jk9fmrhg4.1tjxfjqrhonf6.dlg@xxxxxxxxxxxxx
On Sat, 7 Mar 2009 22:09:24 -0000, Aaron Gray wrote:
"Aaron Gray" <ang.use...@xxxxxxxxx> wrote in message
news:71fi2fFkkubpU1@xxxxxxxxxxxxxxxxxxxxx
I want a OO language with :-
- multiple inheritance - with fine grain control- interfaces, ala Java
No, an abstract type is/has already interface. What is needed is
inheritance of interfaces from concrete types. But no interfaces, it is a
great evil.
In my model interface cannot contain implemeted methods, abstract classes
can.
Yes, I mean that. Interface as a kid of type makes no any sense.
- public, protected, and private, ala C++
No. Visibility is an independent to type issue. It is a property of a
package / module. It has nothing to do with inheritance. So public and
private views only.
no protected members ? Why not ?
Because it is an artefact of C++ design fault which conflates classes and
modules. If you don't then public and private suffice.
- C++ style casts to access "hidden" members
No hidden members. There is "private" for that.
UnlikeEiffeland like C++ member maybe overlayed by other members in
inheriting classes. In Eiffle you cannot ever get access to these again, but
in C++ and my model they maybe accessed via casts, ie X::Y::z
See above. There is no such problem. Derive in a package that has full view
on the type, end of story.
No. Constructor / destructor aren't functions. There should be built-in
constructors / destructors with user defined hooks of *properly* typed
subprograms.
They are static functions with special prominence.
No, they are not since you cannot specify their profile staying typed.
Constructor takes "no type" and converts it into "type T," this i
fundamentally inconsistent with the notion of strong typing.
BTW, under static function I understand "compile time function," and not
C++ kludge.
BTW. These hooks must be definable for class and for type. AKA the issue
of dispatching from a constructor.
How they are called is platform dependant. I have not started designing or
defining the platform yet, it will probably be CLR or Java'ish.
It does not depend on any platform. It is again a fundamental issue, you
cannot dispatch so long there is no object, and there is no object while
you are in the constructor. This can be solved only by introducing
constructors of classes.
- most things/'units' can exhibit inheritance, for example
modules can inherit other modules so extending them.
First-class modules? That's difficult to make working. I doubt if it can
work.
Dont see any problems with first class modules, can you please list some.
How are you going to check types of the objects declared in dynamically
created module object?
- generics/parameterized polymorphism
No generics. Constrained types instead.
Why ?
Generics is a huge mess.
- signatures to allow restricted generacism as well as 'super',
and 'sub', 'parent' and, 'child' restrictors
No, that is weak typing. Ad-hoc supertypes instead.
Signatures are akin to C++0x's concepts although as of yet not as powerful.
I don't buy weak typing. Typing is either strong or none.
- templates or hygenic macros
No templates (which are generics anyway)
Templates or hygenic macros are not generics !
I see no difference. Yes generics as found in Ada are typed, in some meta
sense, while C++ templates are not. Beyond that there is no difference.
- by devorcing templates from generacism you end up withalot more
power, there is no way of adding any extra value to C++ templates and hence
there usefullness is restricted and its back to C preprocessor.
No it can end only in mess.
In C++ templates any value semantics end up in the objects signature which
means it cannot be used for templating proper.
I am not sure what you mean.
This is another way to say that it is a mess. Note that templates is a meta
language related to the object one. This is why you can have templates of
anything. If you need a meta-language, then there is something wrong with
the object one, obviously. So why not to concentrate on fixing that first?
Especially when designed form scratch?
I disagree this is a meta language and an object language, it just depend
what modules you include to what the language provides and is applicable
for.
Addition of any feature to the language must be justified. So far nobody
was able to point any reason why a language should have generics /
templates / macros. All arguments are based on an inability the given types
system to express a certain class of types. See Stepanov's argument about
generic max, for example. These arguments are bogus. Fix the type system
and everything will be OK.
- multimethods, both global and on classes
Multiple dispatch.
Yes, but in a contained fashon using the 'virtual' keyword :)
There should be nothing but virtual. If you don't want a procedure to
dispatch in some parameter, you would declare it on the class rather than
on the type. It will still dispatch but on the class of the class.
You probably mean the interface of a compilation unit and its separation
from the implementation. Everything visible in the declarative part of a
unit is, well, visible.
Unless it is marked private, protected.
When private then invisible. Protected has no meaning.
Protected types, that is ones which can accessed concurrently. Protected
type is an OO view on concurrency, while tasks are a functional one.
What ?
Protected object is passive. Its operations are said to be protected. There
are three kinds of:
- immutable, change no state, synchronous can be executed simultaneously
when you have multi-core;
- mutable, change state, synchronous, mutually exclusive;
- entries, change state, asynchronous, mutually exclusive, can be awaited
for (have a queue).
Protected objects are sufficiently more effective than other means of task
communication, like rendezvous, for example.
+ contracted exceptions
try, throw, catch, and finally.
I meant that each operation has a contract of the exceptions, which may
propagate out of it. The exception contracts are statically checked and
inherited from parent typed. (Java, but with lessons learned.)
+ statically checked pre-/postconditions, invariants
Yes like Eiffle, nice, I had though about these.
No, unlikeEiffel. Meyer did it wrong, IMO. InEiffelthey are assertions.
I meant correctness checks, i.e. everything happens before the run.
Otherwise it makes no sense.
+ abstract interfaces for standard container types (array, record)
+ abstract interfaces for referential types
+ abstract interfaces for aggregates
+ dynamically constrained types
Runtime typing, runtime constraints ? Please clarify ?
Consider an array type, like string. String is unconstrained because its
length is unknown. But this does not mean you need dynamically allocated
strings like in C++. In 90% cases all string objects are constrained (have
known length) on the caller side. But the callee is works with an
unconstrained formal object. This is a very powerful model of type
parametrization without generics.
+ downward closures
please elaborate.
Passing a function as a parameter. The function carries its context with.
+ fully OO 1: no free functions, any function is a method of the types of
every its argument and the type of the result(s). I think this would be
difficult to reconcile with fashionable first-class functions
No we have free functions they are fine as long as they are scopesd within a
namespace, module, or package.
To me any function is virtual. I see no reason to have other kind of
functions. They breaks out of the model. If you have multiple dispatch,
free functions vanish.
+ fully OO 3: every class has a type (polymorphic objects)
A class is an implementation of a type, not necessarily polymorphic thoght,
it may just be aload of inlines !
Class is a set of types. The set of values of the type of the class is a
closure of the sets of values of the types from the class.
+ separation of classes and types (polymorphic vs. specific objects)
types are implemented by other types or classes. We seem to have different
models for types and classes, I donot agree with your distinction.
Yes
+ an ability to have polymorphic objects with value semantics (follows
from OO 2)
Dont follow please explain your model properly.
See above.
Any contenders ?
We will forget about the contenders :)
The problem is that to make that list right is a huge problem. You forgot
the mist important thing, the requirements of how the above aspects shall
be implemented, Say you add to multiple dispatch and obvious requirement:
"no dispatch may fail at run time," and you get a serious problem, since
nobody, AFAIK, knows how to achieve that.
I was not aware of anything like this with multiple dispatch could produce
exceptions if there are undefined usages though.
Lisp's MOF seems to have implemented MD fine.
Could you please elaborate and maybe give an example please.
When you derive S from T and inherit some f, the language shall force you
to define all implementations of f for all possible combinations of the
parameters if it cannot invent an implementation by itself. Consider:
f : T x P
you derive S from T, now there are
f : T x P
-----------------------------
f : S x P (inherited)
let's derive R from P, now we have
f : T x P
f : S x P
-----------------------------
f : T x R (inherited)
lisää »- Piilota siteerattu teksti -
- Näytä siteerattu teksti -- Piilota siteerattu teksti -
- Näytä siteerattu teksti -...
.
- References:
- The Language I want
- From: Aaron Gray
- Re: The Language I want
- From: Aaron Gray
- Re: The Language I want
- From: Dmitry A. Kazakov
- Re: The Language I want
- From: Aaron Gray
- Re: The Language I want
- From: Dmitry A. Kazakov
- The Language I want
- Prev by Date: Re: What is SSA? Tangent from: Re: What's lacking: a good intermediate form
- Next by Date: Re: What's lacking: a good intermediate form
- Previous by thread: Re: The Language I want
- Next by thread: Re: The Language I want
- Index(es):
Relevant Pages
|
