[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: *.mid vs *.midi

From: Hans Aberg
Subject: Re: *.mid vs *.midi
Date: Sun, 18 May 2008 16:19:56 +0200

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
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".


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 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]