binding time in haskell
We have sporadic network problems here and I may have missed an earlier reply. I need to know about binding time in Haskell especially with regard to type variables. Barbara Nostrand mailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: filepath mangling under Windows?
ghc-5.02.2 is not a cygwin application, so it won't understand paths like /d/foo -- it will understand d:/foo and d:\foo though. Internally, the compiler will canonicalise paths to 'platform-native' formats before passing them to external tools, which is why you see the slashes reversed. GHC could with benefit do some verification of -o paths, to avoid the cryptic msg you're seeing -- I'll add it to my ToDo list. hth --sigbjorn - Original Message - From: Malcolm Wallace [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 05, 2002 02:54 Subject: filepath mangling under Windows? With ghc-5.02.2 running from a Makefile in a cygwin shell under Windows XP, the following behaviour occurs: ghc -package lang -package posix -c -o /d/haskell/hmake-3.00/targets/ix86-CYGWIN_NT-5.1/obj/hmake/QSort.o QSort.hs Assembler messages: FATAL: Can't create \d\haskell\hmake-3.00\targets\ix86-CYGWIN_NT-5.1\obj\hmake\QSort.o: No such file or directory It looks like ghc has reversed the slashes in the filepath given to the -o option, and this is the reason the assembler fails. The directory certainly exists, but we suspect cygwin only understands the forward-slash form not the backward-slash form. Is this a bug in ghc? Or is there some option we can give to persuade ghc not to reverse the slashes? Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: filepath mangling under Windows?
ghc-5.02.2 is not a cygwin application, Whilst I was aware that GHC no longer requires Cygwin to run, I didn't realise that it actively discourages use under Cygwin. This issue arose because a Windows user would like to use `hmake' with GHC, and the `hmake' installation currently requires Cygwin. Is there really no possibility of using GHC in the Cygwin environment? Don't know where you get this actively discouraging bit from. You make it sound as if it isn't possible, which certainly isn't the case - you just have to keep in mind that using filepaths that only makes sense wrt. the Cygwin mount table is not a Good Idea, i.e., stuff like /cygdrive/d/foo. (Have a look at the 'cygpath' utility, btw). If you're really that gung-ho about cygwin, you could always compile up GHC using the cygwin toolchain. Internally, the compiler will canonicalise paths to 'platform-native' formats before passing them to external tools, which is why you see the slashes reversed. As far as I understand the Windows filesystem (which I admit is not very far at all), \d\foo is not a canonical pathname, so why is GHC generating it? Because you said /d/foo , which it translated to \d\foo before feeding ut to 'as' (canonical == canonical slashes), which is another non-cygwin application (i.e., we include cygwin-free versions of gcc, as and ld with the ghc installer). --sigbjorn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: filepath mangling under Windows?
Malcolm Wallace [EMAIL PROTECTED] writes: ... Don't know where you get this actively discouraging bit from. I'm sorry, I just meant that it seems to be a little bit more difficult now to get GHC and Cygwin to interoperate than it once was. The situation as I understand it is this: * A user has Cygwin as a preferred environment under Windows. * This user has D:\ mounted in Cygwin as /d/. * Most of the user's applications are found in the path /d/. * But a pre-built GHC does not understand the /d/ paths. * The user has tried changing their Cygwin environment to use D:\ instead of /d/. * Now GHC understands paths properly, but most of his other applications now do not work because of the opposite path issue. What I'm wondering is whether the difficulty is a necessary one, or if it was unintentional, is there an easy fix? From your suggestions, I guess there isn't an easy fix. Right, somehow re-implementing cygwin's open() doesn't sound wise. I don't understand why feeding GHC d:/foo rather than /d/foo has such global ramifications for the user in Q. --sigbjorn ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Double your monad in 30 days
Ashley Yakeley [EMAIL PROTECTED] writes: Prelude 0 * 2 0 We can generalize this. import Monad double_your_monad_in_30_days :: (MonadPlus M) = M a double_your_monad_in_30_days = mzero `mplus` mzero ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
