Re: *.mid vs *.midi

[Hans Aberg]

On 18 May 2008, at 15:16, immanuel litzroth wrote:

> > So the C language itself does not
> > have any #include directive.
>
> Implementation issue. There is no requirement for a separate  
> preprocessor, ...

In the C and C++ standards there are.

> ...and the fact that compilation happens in stages is a feature of  
> most if not all programming languages.

Without it, it is not possible in C to combine contents of files.

> > This setup makes it impossible for the
> > C
> > language to deduce module dependencies the way Haskell does, > which
> >
> > causes the complicated setup of the compiler. And of course, in
> > Haskell, one needs to tell which modules to import.

> C doesn't have modules, so it is definitely impossible for it to  
> "deduce module dependencies".

Right.

> And again you are saying that Haskell deduces module dependencies  
> which is not something I read in the Haskell Standard.

It constructs a module tree somehow. And module imports can be  
recursive.

> It uses modulo some renaming the same compilation model:
> "A multi-module Haskell program can be converted into a single- 
> module program by giving each entity a unique name, changing all  
> occurrences to refer to the appropriate unique name, and then  
> concatenating all the module bodies".

This is probably just to define the language semantics. One can  
program with modules, called name spaces, in C by prepending its name  
to each name of it. This led to the C++ "namespace" construct. But C+ 
+ just inherits the preprocessor #include of C, so it canno do the  
module checking that Haskell can.

> The "make" feature is something that could implemented in a C/C++  
> compiler easily by requiring each #include "xxx" to map to
> a library xxx.o or xxx.lib in abscence of which you just compile  
> xxx.cc in some search path.

This is not possible as #include are not a part of C/C++ but only the  
preprocessor, which is merely a macro-language that combines files  
into a single body of text. And the C/C++ languages deliberately do  
not specify where the stuff output should end up, in order to achieve  
platform independency.

So one is left with creating something like Haskell "import"  
construct. It has been discussed much whether C++ should have it, but  
it did not get it.

  Hans