Attached is a patch to Feb2001 which does the following * flushes stderr when :set -h<size> and :set {+,-}98 is used. As is, the informational messages that's printed on stderr may not appear until later with some terminal & CRT combos. * allows the use of "~/" in :cd commands. ~/ is substituted with whatever the environment variable HOME contains. It doesn't do other forms of tilde expansion, but if there's interest I could always add support for ~login/ i.e., first tweak is a bugfix, the second is a feature tweak. BTW, is there a technical reason why toggling between Haskell98 and Hugs mode can only be done at startup time? --sigbjorn
Hi Sigbjorn! | BTW, is there a technical reason why toggling between Haskell98 | and Hugs mode can only be done at startup time? It was a design philosophy rather than an essential feature. Would it make sense to allow somebody to :set -98, then :load a file containing rank-2 polymorphism, overlapping instances, etc..., then :set +98 and :also a standard Haskell 98 file? What language would they be using at that point? I concluded that it would be better to give Hugs two distinct identities, rather than a confusing and schizophrenic personality that drew no clear lines between +/-98. That said, you could easily hack the code to allow users to switch modes without restarting the interpreter. But it wasn't designed to run that way, so I wouldn't trust it to work correctly either ... All the best, Mark
At 09:29 -0800 2001/03/06, Mark P Jones wrote:
| BTW, is there a technical reason why toggling between Haskell98 | and Hugs mode can only be done at startup time?
It was a design philosophy rather than an essential feature. Would it make sense to allow somebody to :set -98, then :load a file containing rank-2 polymorphism, overlapping instances, etc..., then :set +98 and :also a standard Haskell 98 file? What language would they be using at that point? ... That said, you could easily hack the code to allow users to switch modes without restarting the interpreter. But it wasn't designed to run that way, so I wouldn't trust it to work correctly either ...
I had a C/C++ compiler where one could alter the implementation of some basic types. For example, "double" could be IEEE of local-OS implementation. This appears fine, but unfortunately the linker did know nothing about this, meaning that different settings would make the object codes incompatible. For example, one could not use the library without recompiling, and then still remains the question what object code the library calls (like some low level OS code). The errors produced are quite mysterious: Values become mysteriously screwed, despite that the sources are perfectly OK. Some code could refuse to compile, and it can be hard to figure out why, in view that all sources are OK. So unless the linker knows about the problem and either issues understandable error or knows how to do the right conversions, such language settings features are quite useless. The language C++ has an interesting construct that allows one to mix it with other languages: The implementer of the compiler can add a language X by supporting it in the construct extern "X" { ... } meaning that the stuff { ... } has the extern linkage of the language X. C++ has the requirement the language C should be included, but one can add other language, Pascal, Haskell 98, etc. (By the way, should it be extern "Haskell 98" { ... } or extern "Haskell98" { ... } -- That is, is the official name "Haskell 98" or "Haskell98"?) Anyway, by the use of this construct, the linker always knows which external linkage each code segment has, and so it is possible to join it together in a correct manner. (Adding suitable initializer/terminalizers in the case of C++.) In fact, Haskell could benefit from having such an "extern" language hook. -- In effect, this could serve as the foreign interface that some Haskell implementations have other constructs for. -- But then I agther it is not a "minor tweak" anymore... :-) Hans Aberg
participants (3)
-
Hans Aberg -
Mark P Jones -
Sigbjorn Finne