Re: The Language I want

On Sat, 7 Mar 2009 22:09:24 -0000, Aaron Gray wrote:

"Aaron Gray" <ang.usenet@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.

- abstract classes to facilitate plugin like behaviour, they can
match
methods and also allow addition of new code and "plugin" code, but are not
instantiable in themselfs.

Yes

- 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.

- C++ style casts to access "hidden" members

No hidden members. There is "private" for that.

I wished to have a non-cooperative model of visibility as an option.
Presently "private" is "cooperative", you can still access private thins as
they are mapped in the process space. I would like to have "private" which
is enforced by memory mapping, i.e. you cannot access it by any means
otherwise as stated by the contract. With incoming multicore and
distributed systems it is important.

- class constructors and destructors as well as object constructors
and
destructors

No. Constructor / destructor aren't functions. There should be built-in
constructors / destructors with user defined hooks of *properly* typed
subprograms.

BTW. These hooks must be definable for class and for type. AKA the issue of
dispatching from a constructor.

- 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.

- generics/parameterized polymorphism

No generics. Constrained types instead.

- signatures to allow restricted generacism as well as 'super', and
'sub',
'parent' and, 'child' restrictors

No, that is weak typing. Ad-hoc supertypes instead.

- templates or hygenic macros

No templates (which are generics anyway)

- 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.

- anything (any 'unit' of expression) should be able to be templated
- types
- classes
- functions
- methods
- signatures
- objects
- algebraic datatypes
- cartesian products
- disjoint unions
- tupes
- records
- top, bottom, undefined, unknown
- pattern matching
for algebraic datatypes
- extensible syntax
modules may define syntax extensions to other modules but not
use them within them selfs, they have to be imported (and not included, but
they maybe inherited and the syntax extensions used).

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?

- multimethods, both global and on classes

Multiple dispatch.

- term rewritting

- units
program code is expessed as 'units'
types inheriting from unit are :-
- declarations
- expressions
- initializers
- namespaces
- modules
modules may import, include or inherit other modules
modules contain units
- packages
packages may import, include or inherit other packages
packages contain modules and may contain other packages.

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.

- pure functions
these maybe included in by including the right 'functional'
extension module
and maybe used in free, namespace, nested function, method or in
classes.

Yes, and static functions as well.

- curried functions
this would complete the whole model, but is a very tall order, and
maybe out of bounds for what is expressable in the languages model.

- process objects

Tasks? Yes these must be first-class. Note also they must be inheritable
from.

Anything missing other than coroutines, which I hate so will no include.

(Coroutine is a low-level stuff)

Protected types, that is ones which can accessed concurrently. Protected
type is an OO view on concurrency, while tasks are a functional one.

+ contracted exceptions
+ statically checked pre-/postconditions, invariants
+ abstract interfaces for standard container types (array, record)
+ abstract interfaces for referential types
+ abstract interfaces for aggregates
+ dynamically constrained types
+ delegation support
+ multiple inheritance (probably already mentioned)
+ downward closures
+ 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
+ fully OO 2: every type has a class (yes this includes Boolean)
+ fully OO 3: every class has a type (polymorphic objects)
+ separation of classes and types (polymorphic vs. specific objects)
+ an ability to have polymorphic objects with value semantics (follows from
OO 2)

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. You add a trivial requirement
that your first-class types would be all equal in the sense that you can
inherit from any. Any means any e.g. integer, task, module (you wanted it),
type (here as a type of type!) and you will see where the devil lives...

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

Relevant Pages

  • Re: The Language I want
    ... inheritance of interfaces from concrete types. ... Generics is a huge mess. ... Templates or hygenic macros are not generics! ...
    (comp.lang.misc)
  • Re: Reprise: in out parameters for functions
    ... > 2) multiple inheritance would be supported; ... interfaces; is true for calls through interfaces (as opposed to directly ... adding protected and task support to them is not a ...
    (comp.lang.ada)
  • Re: The Language I want
    ... inheritance of interfaces from concrete types. ... It has nothing to do with inheritance. ... dispatch in some parameter, you would declare it on the class rather than ...   f: T x P ...
    (comp.lang.misc)
  • Re: The Language I want
    ... inheritance of interfaces from concrete types. ... I disagree this is a meta language and an object language, ... Multiple dispatch. ...
    (comp.lang.misc)
  • Re: Trying to understand the purpose of interfaces
    ... Do interfaces get used in ASP.NET or is that more of an executable world? ... your business layer needs to talk to a data layer in order ... layer objects and their representation in a SQL database. ... my SQL database persistence classes have their own inheritance ...
    (microsoft.public.dotnet.languages.csharp)