Re: Ultimate Language feature list

[Charles Hixson <charleshixson@earthling.net>]

Here's my features (at the end), plus some notes (interspersed):

MSG wrote:
> 
> I do all my development in C++.  Not necessarily because I want to, but
> because I keep looking (and looking) for alternate languages/environments
> and they ALWAYS come up short.  I've decided that the language/environment
> for me hasn't been created, so I'm starting a list of features that I
> like/require.  It's drawn from good languages (I don't consider C++ a "good"
> language", neither is Java).  If anyone would care to contribute, please
> feel free.  Who knows, maybe with enough interest we can create a
> language/environment we REALLY like and that works easily on any platform,
> allowing you to use a sophisticated  language and still access platform
> specific features for truly fantastic and stable applications.
> 
> I hope a posting like this doesn't cause a flame war.  I'm just sharing my
> feelings and hoping that some interest will spark -- to what end, I'm not
> sure.
> 
> Michael Scott Garnett
> michael@pickles.org
> 
> #1 Verbosity.  C++ and Java's cryptic syntax is cute and fun, but not
> useful.  Our Language (OL -- come up with a good name) should be verbose
> like Ada and Eiffel.  Semicolons optional like Eiffel (except where
> ambiguous).
Verbosity has it's points, but so does compactness.  Zipf's laws rules
here.  Frequently used features should be v. short, e.g. {} is better
than Begin End

> #2 Completely OO.  No free floating subroutines.  The only construct higher
> than a CLASS is an Organizational Unit (like an Eiffel cluster).
Object Orientation is the correct solution for certain classes of
problems, so the lanugage should support a totally object oriented
style.  It shouldn't insist on it.  Byte arrays use up enormous amounts
of storage when each byte is an object.

> #3 Object-Dot-Feature syntax.  No Ada95esque subprograms which take class
> arguments (like C++ friend functions).  I am torn between Object-Dot-Feature
> and Object SPACE feature syntax (like Smalltalk).
What about context specifier?  3 + 5 vs. "3" + "5" vs. 3.0 + 5
These can all be understood by a person, a compiler might reason: given
a number, the operation + probably means addition, so check for the next
argument.  If types are staticly determined, then this is either
ambiguous or determined at compile time.  The question is what to do if
it is ambiguous at run time.  Note that the semantics is the same as
object-dot-feature.  Ideally, syntax should be flexible, and I don't
know what's practical.

> #4 Reference Objects as a default with the ability to expand an object or
> class to full form (like Eiffel EXPANDED types)
This is good.

> #5 Garbage Collection.
This is v. important.

> #6 Construction and Finalization
This needs to be elaborated, Final means something different in Java
than it does in Eiffel, e.g.

> #7 Predictable Finalization for stack-based objects (either reference or
> expanded).  When the immediately enclosing scope terminates, the
> finalization is called THEN. This is VERY important for reliable external
> resource management (OK, C++ did this right).
Predictable or controlable?

> #8 Polymorphism as the rule.  Let the compiler figure out which routines are
> not overridden and use static calls where appropriate (a la Eiffel).
Yes.

> #9 Named arguments.  Either like Ada or like Smalltalk (object moveTo: here
> usingPath: aPath).
Good, although I've rarely used that feature when it was available. 
Still, it facilitates indirect object style constructions.

> #10 Array and record aggregates (like Ada).
YES!!! Nobody else has (except, poss. PL/1) that I've encountered has
done arrays as well.

> #11 Multiple inheritance like Eiffel, NOT C++.
Yes, especially the rename and redefine constructs.

> #12 STRONG typing and constraint/program checking in the compile and runtime
> like Ada.  Options to remove such features in a "finalized" version is very
> much necessary.
Strong typing should be available, and when used should allow compiler
optimizations.  However, a more perfect language would also allow
"on-the-fly" constructions and evaluations (ala Lisp, Snobol, etc.)

> #13 Ada-style tasks.  Using Object-as-task, like the proposed Eiffel
> extension "separate".  Ada's SELECT mechanism.  Protected types (like
> Ada95), Java almost got this right.
I wish that I understood this better.  It sounds good, but I don't know
the details of what it means.

> #14 EASY access to other languages/calling conventions.  Any CLASS's
> features my be effected by external other-language routines. The includes an
> easy way to link to C++ libraries.  Such special classes can specify that
> for "THIS" an other-language-notion be used. Such classes would lack
> "variables", being limited to routines only.
Yes.

> #15 Generics.  Not templates.
Yes.

> #16 Intrinsic types (like Integer) as objects, but completely replaced in
> generated code by native types (like Eiffel).
As long as they DO get replaced, or at least can be.  Possibly some
constructions could require that object style information be carried
after compilation, but certainly arrays of intrinsic type shouldn't
require that each of their members be a separate object.
#16b:  Homogenous arrays:  In a homogenous array, all members of the
array are of EXACTLY the same type (whether or not it is intrinsic), so
indirect references, etc. are not needed, and storage (etc.) can be
optimized.

> #17 Ada's float types (delta, digits).
Yes.

> #18 Range specifications (like Ada).  Checked at compile time and run time.
Yes.

> #19 Discriminated record/class types (like Ada).  Checked at compile time
> and run time. (maybe not necessary with inheritance)
I'm unsure of this one.  Inheritance seems to me to be a better choice.

> #20 An easy with to extend and re-expose/hide features of parents.  Like
> Eiffel.
No (and yes).  One needs the private type as well as the protected
type.  Possibly there could be a Discrete type that was by default
hidden, but which the descendants of could Peek at?

> #21 Distributed computing.
Yes, but what does this mean (beyond separable threads (or tasks)?)

> #22 Pre- and post-conditions (from Eiffel).  Including support for the "old"
> keyword.  The closest thing to Z (pronounced Zed - a formal method) that
> I've seen.
Yes.

#23 Pattern Matching primitives and forms.  A bit up in the air here,
since I'm not sure the best way to blend it in.

#24 Built in database (not an add-on).  This could be a compiler option,
but needs to be an integral feature of the language, not a JDBC style
add-on.

#25 Good random-access I/O capability.  At least for homogenous files
(see homogenous arrays, above) this should be easy.  I would like
something better, however.  Something that doesn't assume that
everything on the disk can fit into RAM, too.

#26 Support for property lists.  This could probably be done via a
library, but it should be a part of the language definition, so that it
is a transportable feature.


-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us