RE: [Haskell-cafe] File path programme
On 25 January 2005 19:45, Duncan Coutts wrote:
On Tue, 2005-01-25 at 19:12 +0000, Ben Rudiak-Gould wrote:
My concern here is that someone will actually use the library once it ships, with the following consequences:
1. Programs using the library will have predictable (exploitable) bugs in pathname handling.
2. It will never be possible to change the current weird behavior, because it might break legacy code. The System.FilePath library will have to remain in GHC forever in its current form, enticing programmers with its promise of easy pathname handling and then cruelly breaking its contract.
If no one uses it in production code then we can fix it at our leisure, and having it out there with "experimental" status isn't necessarily a bad thing in that case. It just feels like we're playing a dangerous game.
That's a sufficiently persuasive argument for me!
Could we just punt this library for this release. After all we can add libraries in a later point release (eg 6.4.1) you just can't change existing APIs.
We can't add libraries in a point release, because there's no way for code to use conditional compilation to test the patchlevel version number. This seems to be a common misconception, probably brought about by the fact that the time between major releases of GHC is getting quite long. Perhaps I should stop writing email and get some work done :) Cheers, Simon
On Wed, Jan 26, 2005 at 01:39:01PM -0000, Simon Marlow wrote:
We can't add libraries in a point release, because there's no way for code to use conditional compilation to test the patchlevel version number.
On the other hand, darcs doesn't rely on version numbers when looking for libraries (instead, it sees if they exist by trying to compile with them), so this constraint isn't necesary for *all* ghc users. -- David Roundy http://www.darcs.net
On Wed, Jan 26, 2005 at 01:39:01PM -0000, Simon Marlow wrote:
On 25 January 2005 19:45, Duncan Coutts wrote:
On Tue, 2005-01-25 at 19:12 +0000, Ben Rudiak-Gould wrote:
My concern here is that someone will actually use the library once it ships, with the following consequences:
1. Programs using the library will have predictable (exploitable) bugs in pathname handling.
2. It will never be possible to change the current weird behavior, because it might break legacy code. The System.FilePath library will have to remain in GHC forever in its current form, enticing programmers with its promise of easy pathname handling and then cruelly breaking its contract.
If no one uses it in production code then we can fix it at our leisure, and having it out there with "experimental" status isn't necessarily a bad thing in that case. It just feels like we're playing a dangerous game.
That's a sufficiently persuasive argument for me!
Could we just punt this library for this release. After all we can add libraries in a later point release (eg 6.4.1) you just can't change existing APIs.
We can't add libraries in a point release, because there's no way for code to use conditional compilation to test the patchlevel version number.
This seems to be a common misconception, probably brought about by the fact that the time between major releases of GHC is getting quite long. Perhaps I should stop writing email and get some work done :)
too bad we can't do things like #if exists(module System.Path) import System.Path #else ... #endif I still find it perplexing that there isn't a decent standard haskell preprocessor.... John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham
too bad we can't do things like
#if exists(module System.Path) import System.Path #else ... #endif
I still find it perplexing that there isn't a decent standard haskell preprocessor....
For my language Kogut I designed a syntax ifDefined condition { something } otherCondition { something else } ... where a condition is an identifier whose definedness is tested, or "module ModuleName" for existence of a module, or _ which is always true, or their combination using conjunctions, alternatives and negations. The construct can be an expression (no condition is true => Null, which makes sense with dynamic typing), a definition (no condition is true => nothing is defined) or a pattern (no condition is true => a pattern which never matches). It does not subsume Common Lisp's #+ and #- nor vice versa. In Lisp it is done at read time, not compile time, which has some advantages, but is incompatible with temporal separation of compilation phases. Even though definitions may in general be mutually recursive, similarly as in Haskell, ifDefined depends only on definitions above it. This is hard to avoid, because its expansion may influence the set of definitions which will be present. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (4)
-
David Roundy -
John Meacham -
Marcin 'Qrczak' Kowalczyk -
Simon Marlow