Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!lll-winken!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!westmark!mole-end!mat
From: mat@mole-end.UUCP (Mark A Terribile)
Newsgroups: comp.lang.c++
Subject: Re: Problems maintaining header files
Summary: What is progress and what is regress
Message-ID: <480@mole-end.UUCP>
Date: 3 Feb 91 07:58:07 GMT
References: <15917@reed.UUCP> <6107@stpstn.UUCP> <486@eiffel.UUCP> <7091@exodus.Eng.Sun.COM>
Organization: mole-end--private system.  admin: mole-end!newtnews
Lines: 66

> >>	For that matter, with Eiffel there is no need for header files
> >>or make files of any kind. The compiler takes care of analyzing
> >>dependencies (by analyzing the source text, which is where the
> >>information is, and the only place where it should be) ...
 
> >Unfortuantely, Dr. Meyer has committed the one great sin of academia: he
> >has become religious about a single idea.  ...
 
> I think you have missed the point; these features need not be unique
> to Eiffel.  Granted, Meyer takes a more extreme position (analyze the
> source text) than I do, but "header files" that are something merged
> into the source text by a pre-processor are really not a very good
> idea.  Separate interface files in the style of Mesa and Modula are
> much more useful.  ...

All of this requires that the programming language also specify the
programming environment.  It also means that things that are built for the
language can be used for nothing else.  Is there a YACC or bison for Eiffel?
Can the `real' source be managed by the same mechanism that manages
dependencies over the Eiffel?

There are good reasons for not building the environment into the language;
the tendency to circumscribe the language is one of them.

As far as making interface seperate from the specification of the type:
That messes up such things as inline functions, or else it requires that the
symbol resolution (first part of linking) be done BEFORE code generation.  It
would be nice to have that capability, but most programming environments do
not support it, and you need the support of the environment if you want to
be sure that native code which you generate will be accepted by that
environment.

I agree that things could be better.  It might even be possible to incorporate
better things into C.  But not everything that does the gee-whizbang thing
you think you want is really better.

> I suppose I'm preaching to the unconvertable, but it seems unusual
> that someone would damn a language feature that they haven't tried.
> I've tried both, and I know which one I like better.

Well, there are some things to which *I* can be converted, and there are
others to which I cannot be converted.  Hot-shot environments that are so
smart I can't make them smarter on my terms are one thing that I will do
without, thank you.
 
> Note, too, that in the system I used (Modula-3) we did make use of the
> pre-processor from time to time, but only for those things where it
> was the most appropriate tool (e.g., OS-dependent changes to data
> structures, not simulating interfaces by file inclusion).  We had a
> stub generator, a data marshalling generator, a makefile generator
> (because we didn't really feel like duplicating the entire function of
> make), a compiler server (that cached interface files for subsequent
> compiles), consistency checkers, a C-generating compiler, and an
> interpreter.  We used our tools to build new tools, and we were very
> productive.

All well and good ... but in a circumscribed environment you couldn't have
done any of them.

Dependency generators for Make on C and C++ are rather trivial, especially
on the Sun but also on other systems; all you have to do is needle the
preprocessor.  A few lines of  ksh  will do the job.
-- 

 (This man's opinions are his own.)
 From mole-end				Mark Terribile