Re: The Language I want

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
news:lr4jk9fmrhg4.1tjxfjqrhonf6.dlg@xxxxxxxxxxxxx
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.

In my model interface cannot contain implemeted methods, abstract classes
can.

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

no protected members ? Why not ? I have public, protected and private and
inheritance pertaining to both classes, modules and packages.

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

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

Unlike Eiffel and 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

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.

They are static functions with special prominence.

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.

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

- generics/parameterized polymorphism

No generics. Constrained types instead.

Why ?

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

- templates or hygenic macros

No templates (which are generics anyway)

Templates or hygenic macros are not generics !

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

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

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.

- multimethods, both global and on classes

Multiple dispatch.

Yes, but in a contained fashon using the 'virtual' keyword :)

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

Unless it is marked private, protected.

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

Yes :)

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

Yep they are special classes with a message passing level, a signals level,
....

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.

What ?

+ contracted exceptions

try, throw, catch, and finally.

+ statically checked pre-/postconditions, invariants

Yes like Eiffle, nice, I had though about these.

+ 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 ?

+ delegation support

Never liked delegation but it should be there, in a language extension
module that supports it.

+ multiple inheritance (probably already mentioned)

Yes that was at the top.

+ downward closures

please elaborate.

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

+ fully OO 2: every type has a class (yes this includes Boolean)

Yes, in the preludes.

+ 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 !

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

+ an ability to have polymorphic objects with value semantics (follows
from
OO 2)

Dont follow please explain your model properly.


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.

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

ineriting from an integer gives the ability for a class/type to look like an
integer but to over ride an integers behaviour, setter and getters will be
implemented like this.

As a type of a type you mean type variables ?

I have been studying this devil for years, and think I have mainly rational
"working" solutions.

Thanks for the examination Dmitry, that was good.

Aaron


.

Relevant Pages

  • Re: The Language I want
    ... inheritance of interfaces from concrete types. ... packages may import, ... multiple inheritance ...
    (comp.lang.misc)
  • 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: 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)