Re: Need input on designing a new language

henry@zoo.toronto.edu
Mon, 4 Jun 90 21:24:34 GMT

          From comp.compilers

Related articles
Need input on designing a new language ramsey@ncoast.ORG (1990-05-26)
Re: Need input on designing a new language henry@zoo.toronto.edu (1990-06-01)
Re: Need input on designing a new language klefstad@opera.ICS.UCI.EDU (Ray Klefstad II) (1990-06-04)
Re: Need input on designing a new language henry@zoo.toronto.edu (1990-06-04)
Re: Need input on designing a new language praxis!itcp@relay.EU.net (Tom Parke) (1990-06-06)
| List of all articles for this month |
Newsgroups: comp.compilers
From: henry@zoo.toronto.edu
Date: Mon, 4 Jun 90 21:24:34 GMT
Organization: Compilers Central
Keywords: design
In-Reply-To: <1990Jun4.044526.14926@esegue.segue.boston.ma.us>

> 4) language support for good software engineering ...
>C) allowing arbitrary declaration and use order (use before declaration
> is ok) ...
> Approach C: ...
> 4: poor (How do you get semantic checking across modules?
> An optional pass by a lint-like program? Yuck!)


Semantic checking across modules is a necessity, and there is only one way
to do it: gather information from all the modules, and compare. The
question is whether that is done automatically (either by the compiler
or by a separate program), or whether the programmer is forced to do some
of the work by contorting his program structure to facilitate checking.
I take the strange and unpopular :-) position that such mechanical busywork
ought to be done by software, not by me.


If you insist on seeing it in terms of header files that have to be
included for compilation, consider having some part of the implementation
generate them automatically, rather than demanding that the user do it.
This also avoids the standard problem of header files, to wit that they
get out of step with the code they claim to describe.


The extra processing time is irrelevant; if minimizing the CPU time needed
to compile my programs was all-important, I would write them in hexadecimal.
I have no liking for slow compilers, mind you, but if that CPU time is
being spent doing something useful -- like performing tasks that would take
much longer if done by hand -- I'm all for it.


Incidentally, Ray's article is a classical example of what's wrong with
header files, since understanding his assessments of the different methods
needed constant flipping back and forth between the assessments and his
definitions of aspects 1-4 and methods A-C.


On a broader topic, I'm in agreement with him that defining a new
general-purpose language is likely to be a futile exercise. To gain any
popularity at all, a language either has to fill some specialized niche
that existing languages address poorly, or be an order of magnitude
better than they are at what they already do. Small improvements are
not sufficient, because they do not justify the pain of conversion and
incompatibility.


                                                                        Henry Spencer at U of Toronto Zoology
                                                                henry@zoo.toronto.edu uunet!attcan!utzoo!henry
--


Post a followup to this message

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