Re: Looking for new language features

"Georg Lokowandt" <georg.lokowandt@sap.com>
23 Sep 2000 14:49:12 -0400

          From comp.compilers

Related articles
[5 earlier articles]
Re: Looking for new language features mq@maq.org (2000-09-11)
Re: Looking for new language features rosing@peakfive.com (Matt Rosing) (2000-09-11)
Re: Looking for new language features rhyde@cs.ucr.edu (Randall Hyde) (2000-09-13)
Re: Looking for new language features viczh@uic.edu (Victor Joukov) (2000-09-15)
Re: Looking for new language features adrian@dcs.rhbnc.ac.uk (2000-09-17)
Re: Looking for new language features mr@peakSPAMLESSfive.com (Matt) (2000-09-21)
Re: Looking for new language features georg.lokowandt@sap.com (Georg Lokowandt) (2000-09-23)
Re: Looking for new language features vbdis@aol.com (2000-09-28)
Re: Looking for new language features rhyde@cs.ucr.edu (Randall Hyde) (2000-10-01)
Re: Looking for new language features idbaxter@semdesigns.com (Ira D. Baxter) (2000-10-06)
Re: Looking for new language features mr@peakSPAMLESSfive.com (Matt) (2000-10-06)
Re: Looking for new language features dsl@tepkom.ru (Dmitri Lomov) (2000-10-08)
Re: Looking for new language features hannah@mamba.pond.sub.org (2000-10-22)
| List of all articles for this month |

From: "Georg Lokowandt" <georg.lokowandt@sap.com>
Newsgroups: comp.compilers
Date: 23 Sep 2000 14:49:12 -0400
Organization: SAP AG
References: 00-08-130
Keywords: design



William Rayer <lingolanguage@hotmail.com> schrieb in im Newsbeitrag:
> Does anyone know of any resources, web sites, documents etc which have
> details of new language features? What I am looking for is a sort of
> wish list of features that could be included in a new computer
> language. It does not matter if the features are complex or high level
> or hard to implement, I'm looking more for ideas than implementation
> detail.


Well, there are 5 points on my wishlist:


1) A small language with many problem-specific language-features
(sounds like a contradiction): If I am a developer of device-drivers I
want access to every bit, as application developer a abstract
DB-Interface is on my wishlist. Possible solution: The language offers
elements for every task and the user has the ability to activate only
those features that he wants to use in a module. For instance this can
be accomplished by importing the statements and operators at the
beginning of a compilation unit. In this way a beginner can start with
the basics. The compiler can give more suitable error messages. There
should be only one good way to specify any semantics. All other ways
should at least be flagged with a warning.


2) Consistency check: If several functions have the same name/the same
operator, they should do the same. This applies to overloaded
functions and to different, independent name-hierarchies. I know this
can't be proven in the general case, but i once had a very hard time
finding an overloaded operator "min" that was actually calculating the
"max" function.


3) Alternative implementations: If there are different implementations
to one interface i want to provide all of them and the compiler should
choose the optimal for a given situation. (And check that they all do
the same, see above)


4) Redundency check: If there are different implementations to the
same abstract type/functionallity with different names, the
compiler/global analyser should give me a hint.


5) defined "unspecified behaviour": If different implementations for
one function don't do the same for some parameter-combination, this
combination should be recognized as "unspecified behaviour" and should
result in the same behaviour on all implementations (exception!)


Hth
Georg Lokowandt


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.