CLAS

[John van Groningen]

>2.  Because Clean is a layout-sensitive language,
>    DISTRIBUTED CLEAN SOURCES SHOULD NEVER *EVER* CONTAIN TABS.
>
>    I would like to be able to use the *same* source files on my Unix
>    systems (where tabs are by default and for all practical purposes
>    immutably set to 8) and on my and my students Mac boxes (where
>    tabs are whatever Clean wants them to be, is it 3 or 4?).

So do we. Therefore the Clean compiler always assumes that tabs have the=
 same size (4) on all systems. If the tab size would be 8 on unix and 4 on=
 the mac and pc, you could get compilation errors when source files are=
 moved between those systems. The compiler and IDE also support text files=
 with the wrong new line codes for the platform.

>    Ok, so on a Unix box it is easy enough to do
>
>        for F in *.?cl ; do
>            mv $F $F.BAK
>            pr -t -e4 $F.BAK >$F
>        done
>
>    but it's even easier if the original developer makes sure there are
>    no tabs in the first place so that NOBODY has to do this.  I was
>    lucky this time, guessing -e4 seems to have worked.  But why should
>    I have to guess?

Tabs can also be expanded or unexpanded with expand or unexpand.

>For what it's worth, I have suggested to the Clean team before that
>allowing special header comments like
>    //charset=3Diso-latin-1 tabs=3D4
>would help a lot.=20

This would cause problems when a source file with tab size 8 is moved to a=
 mac or pc, because the editor does not recognize the header comment and=
 would show the source file with a different tab size.

Why not tell the editor that the tab size is 4. For example for emacs, start=
 .icl and .dcl files with the following line:
// -*- tab-width: 4 -*-
or use:
(setq-default tab-width 8)
in your .emacs file.

Or even better, tell your editor to use tab size 4 for all .icl and .dcl fil=
es.

John van Groningen