Re: [Haskell-cafe] A restricted subset of CPP included in a revision of Haskell 98
[ I'm just working through a large backlog of mails, so the original message is a bit old... :-) ] Am Sonntag, 20. August 2006 22:37 schrieb Henning Thielemann: On Thu, 17 Aug 2006, Brian Smith wrote: [...] I think there should be more effort to avoid CPP completely. My experiences with Modula-3 are, that you can nicely separate special-purpose stuff into modules which are included depending on some conditions. Say you want the same module both for Windows and Unix, you provide directories WIN32 and POSIX containing implementations with the same interface and then the make system can choose the appropriate directory. [...] That's a nice theory, but this doesn't work in practice, at least not for me. The problem in my OpenGL/GLUT/... bindings is that the calling convention to the native libraries is different on Windows, and there is no Haskell way to parametrize this. Therefore using a preprocessor is the only sane way I see here. Having to duplicate e.g. 567 foreign imports just to avoid CPP in the OpenGL package is a rather bad tradeoff IMHO. Almost everything is better than redundancy, even CPP... Another use of CPP in the OpenGL package is to access OpenGL extension entry points. Here CPP is used to generate a 'foreign import dynamic' and two Haskell functions per extension entry. Perhaps this could be done via TH, but this would limit the portability, again a bad tradeoff. I would be glad if there were other ways to achieve these things, but I fail to see them. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A restricted subset of CPP included in a revision of Haskell 98
On Thu, 17 Aug 2006, Brian Smith wrote: I find it strange that right now almost every Haskell program directly or indirectly (through FPTOOLS) depends on CPP, yet there is no effort to replace CPP with something better or standardize its usage in Haskell. I think there should be more effort to avoid CPP completely. My experiences with Modula-3 are, that you can nicely separate special-purpose stuff into modules which are included depending on some conditions. Say you want the same module both for Windows and Unix, you provide directories WIN32 and POSIX containing implementations with the same interface and then the make system can choose the appropriate directory. See for example the handling of line end coding in Windows and Unix: http://www.elego-software-solutions.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/rw/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A restricted subset of CPP included in a revision of Haskell 98
Hi, I find it strange that right now almost every Haskell program directly or indirectly (through FPTOOLS) depends on CPP, yet there is no effort to replace CPP with something better or standardize its usage in Haskell. According to the following document, and my own limited experience in reading Haskell code, CPP is the most frequently used extension: http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions I think that if we accepted that CPP was part of the language, we could then place some restrictions on its use to facilitate easier parsing. Here are some suggestions, off the top of my head:* #define can only be used for parameterless definitions* #define'd symbols are only visible to the preprocessor * #define can only give a symbol a value that is a valid preprocessor _expression_* #define can only appear above the module declaration* a preprocessor symbol, once defined, cannot be undefined or redefined * #include and #undef are prohibited* The preprocessor can only be used at the top level. In particular, a prepropcessor conditional, #error, #warn, #line would not be allowed within the export list or within a top-level binding. * A Haskell program must assume that any top-level symbol definitions are constant over the entire program. For example, a program must not depend on having one module compiled with one set of command-line preprocessor symbol bindings and another module defined with a different set of bindings. * preprocessor directives must obey Haskell's layout rules. For example, an #if cannot be indented more than the bindings it contains.The result would be:* Syntax can be fully checked without knowing the values of any preprocessor symbols. * Preprocessor syntax can be added easily to a Haskell parser's BNF description of Haskell.* No tool will need to support per-file/module preprocessor symbol bindings.Again, all this is just off the top of my head. I am curious about what problems these restrictions might cause, especially for existing programs. I know that GHC itself uses some features that would be prohibited here. But, GHC is really difficult for tools to handle even with these restrictions on its source code. For now, I am more interested in the libraries in FPTOOLS and users' programs. What libraries/programs cannot easily be reorganizated to meet these restrictions? I suspect #define'd symbols are only visible to the preprocessor would be the most troublesome one. Thanks,Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A restricted subset of CPP included in a revision of Haskell 98
On 8/17/06, John Meacham [EMAIL PROTECTED] wrote: On Thu, Aug 17, 2006 at 11:44:17AM -0500, Brian Smith wrote: Hi, I find it strange that right now almost every Haskell program directly or indirectly (through FPTOOLS) depends on CPP, yet there is no effort to replace CPP with something better or standardize its usage in Haskell. see this paper for some interesting work on the subject.http://citeseer.ist.psu.edu/wansbrough99macros.htmlThanks for that. I should have not said there is no effort to replace CPP before. I hope I did not offend anybody that has worked on this problem previously. I was also mistaken in saying that syntax could be fully checked without knowing any preprocessor symbol bindings. This is only true if one gets rid of the ability to choose between two syntaxes via the preprocessor. But, if we allow syntax that we can't parse (but presumably another implementation can), then the preprocesor must remain a true preprocessor. Then there isn't much reason to place so many restrictions on where the various preprocessor directives may appear. I proposed to limit where #define could appear mostly for asthetic reasons. If #define, #error, and #warn only appear at the beginning of a file, then the rest of the file would only contain Haskell syntax in between #if...#else...#endif. Also, a refactoring tool would not have these directives get in its way. I want to have conditionals limited in their placement to make things easier for refactoring tools. But, I don't have any ideas about how to deal with conditional exports without allowing preprocessor conditionals in the export list. * #define can only be used for parameterless definitions* #define'd symbols are only visible to the preprocessor * #define can only give a symbol a value that is a valid preprocessor _expression_* #define, #error, and #warn can only appear above the module declaration* a preprocessor symbol, once defined, cannot be undefined or redefined with a different value * #include and #undef are prohibited* The preprocessor can only be used at the top level. In particular, a prepropcessor conditional or #line would not be allowed within the export list or within a top-level binding. * A Haskell program must assume that any top-level symbol definitions are constant over the entire program. For example, a program must not depend on having one module compiled with one set of command-line preprocessor symbol bindings and another module defined with a different set of bindings. * preprocessor directives must loosely obey * #define can only be used for parameterless definitions* #define'd symbols are only visible to the preprocessor * #define can only give a symbol a value that is a valid preprocessor _expression_* #define can only appear above the module declaration* a preprocessor symbol, once defined, cannot be undefined or redefined * #include and #undef are prohibited* The preprocessor can only be used at the top level. In particular, a prepropcessor conditional, #error, #warn, #line would not be allowed within the export list or within a top-level binding. * A Haskell program must assume that any top-level symbol definitions are constant over the entire program. For example, a program must not depend on having one module compiled with one set of command-line preprocessor symbol bindings and another module defined with a different set of bindings. * preprocessor directives must obey a very simple layout rule: an #if, #else, or #endif cannot be indented more than the bindings it contains. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A restricted subset of CPP included in a revision of Haskell 98
brianlsmith: Hi, I find it strange that right now almost every Haskell program directly or indirectly (through FPTOOLS) depends on CPP, yet there is no effort to replace CPP with something better or standardize its usage in Haskell. According to the Note also cpphs, http://www.cs.york.ac.uk/fp/cpphs/ -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A restricted subset of CPP included in a revision of Haskell 98
Even though I'm largely responsible for making CPP available in a Haskell compiler I think it's an abomination. It should be avoided. If we standardize it, people will use it even more. I think we should discourage it instead, then looking at exactly what it's used for and supplying sane versions of it. -- Lennart On Aug 17, 2006, at 12:44 , Brian Smith wrote: Hi, I find it strange that right now almost every Haskell program directly or indirectly (through FPTOOLS) depends on CPP, yet there is no effort to replace CPP with something better or standardize its usage in Haskell. According to the following document, and my own limited experience in reading Haskell code, CPP is the most frequently used extension: http://hackage.haskell.org/trac/haskell-prime/wiki/ HaskellExtensions I think that if we accepted that CPP was part of the language, we could then place some restrictions on its use to facilitate easier parsing. Here are some suggestions, off the top of my head: * #define can only be used for parameterless definitions * #define'd symbols are only visible to the preprocessor * #define can only give a symbol a value that is a valid preprocessor expression * #define can only appear above the module declaration * a preprocessor symbol, once defined, cannot be undefined or redefined * #include and #undef are prohibited * The preprocessor can only be used at the top level. In particular, a prepropcessor conditional, #error, #warn, #line would not be allowed within the export list or within a top-level binding. * A Haskell program must assume that any top-level symbol definitions are constant over the entire program. For example, a program must not depend on having one module compiled with one set of command-line preprocessor symbol bindings and another module defined with a different set of bindings. * preprocessor directives must obey Haskell's layout rules. For example, an #if cannot be indented more than the bindings it contains. The result would be: * Syntax can be fully checked without knowing the values of any preprocessor symbols. * Preprocessor syntax can be added easily to a Haskell parser's BNF description of Haskell. * No tool will need to support per-file/module preprocessor symbol bindings. Again, all this is just off the top of my head. I am curious about what problems these restrictions might cause, especially for existing programs. I know that GHC itself uses some features that would be prohibited here. But, GHC is really difficult for tools to handle even with these restrictions on its source code. For now, I am more interested in the libraries in FPTOOLS and users' programs. What libraries/programs cannot easily be reorganizated to meet these restrictions? I suspect #define'd symbols are only visible to the preprocessor would be the most troublesome one. Thanks, Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
