[Haskell-cafe] Re: When to teach IO

jerzy.karczmarczuk at info.unicaen.fr jerzy.karczmarczuk at info.unicaen.fr
Thu Dec 22 06:43:51 EST 2005


Ketil Malde writes: 

> I'm sorry, but, if we define "compiler" as a input->process->output
> pipeline, then: 
> 
>   "shuffling and transforming data" = compiler
>   "transforming data for reports" = compiler 
> 
> I actually think a lot of useful programs fit into that category.

Ketil, calling "compiler" all this stuff you mention, simply
desintegrates the very definition of compilation. ALL is compiler...
An image synthesis program (say, a ray-tracer like POV-Ray) is a
compiler. TeX is a compiler. Etc. ... Perhaps, if you wish. But still,
most people *USE* TeX or POV-Ray to make images or formatted documents. 

So, I think that your opponent (was it Alistair Bayley?) is mostly
right claiming that people *write compilers* rarely. Even if I accept
your philosophy that all/most data processing activities is a *kind*
of compilation, in order to keep some minimum of discipline, I believe
that it is good to assume that 

+ Compilers are *universal*; they should handle a large set of sources,
 transforming them in something digested, reformatted, rendered visually
 etc.
+ The output of the compiler *should, at least conceptually* preserve the
 semantics - as we see it - of the source. Thus, say, a game is not
 a compiler.
+ They are more or less autonomous. TeX is a compiler. An add-on, say,
 a LaTeX macro-package (or an #included script to POV-Ray) are not, they
 just enrich the grammar of processed documents.
+ Compilers must respect some criteria of decency. (This is my idée
 fixe, I used to insist on that during all my compilation courses...)
 They are not allowed to break on erroneous data. They MUST terminate
 (gracefully). Etc. 

What is the percentage of programs written by average Norwegian salmon
eaters which respect that? Concerning local French snail-eaters ... well,
I lost all illusions quite a time ago. 

Jerzy Karczmarczuk 

PS. About the subject (when to teach IO): don't be sectarians. If
   a programming course insists on algorithmics, the IO issues can be
   postponed a bit. If it insists on practical data processing, IO
   should come in immediately. A programming course should be
   harmonious, homogeneous, well assembled, interesting, and easy to
   put into practice (...sorry for triviality, you ALL know that...),
   and the details depend on the language and on the teacher. In Scheme
   it is easier than in Haskell. 




More information about the Haskell-Cafe mailing list