[Haskell-cafe] problem building hmake on Mac OS X
Hello everyone, I'm trying to build hmake on version 10.3.6 of Mac OS, having installed the ghc 6.2.2 dmg I found on haskell.org, but I'm encountering the following problem: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ make cd src/hmake; make HC=ghc all config /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7/config:9: *** missing separator. Stop. make: *** [targets/powerpc-Darwin7/hmake-ghc] Error 2 Here's lib/powerpc-Darwin7/config: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ cat lib/powerpc-Darwin7/config BUILDWITH=ghc BUILDOPTS= INSTALLVER=3.09 (2004-11-13) INSTALLINFO=config: powerpc-Darwin7/ by [EMAIL PROTECTED] on Thu Dec 2 04:43:46 EST 2004 BUILDBASEDIR=/Users/sge/haskell/hmake-3.09/targets READLINE=-DUSE_READLINE=1 -lreadline EXE= GHCSYM=#pragma GCC set_debug_pwd /Users/sge/haskell/hmake-3.09 602 TRUE=/usr/bin/true In case Gmail wraps this, line 9 has the oracular '602'. Finally, here's the ./configure output: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ ./configure --prefix=/usr/local Configuring for hmake... [ 3.09 (2004-11-13) ] Looking for already-installed Haskell compilers: Looking for hbc... (not found) Note: LMLDIR/HBCDIR variables must be set to enable detection of hbc. Looking for ghc... found 6.2.2 Looking for nhc98... (not found) I am guessing that you want to use ghc to build hmake. Now I'm creating targets/powerpc-Darwin7/hmake3.config for your installation. Done. Configuration report for hmake. (You can re-run configure to change settings before proceeding.) You wish (eventually) to install the following components in these locations: (Installation directories are not created/checked at this stage.) Final install root: /usr/local hmake binaries: /usr/local/lib/hmake/powerpc-Darwin7 Scripts: /usr/local/bin Man pages:/usr/local/man/man1 Now we check/create your build directories: Config directory: targets/powerpc-Darwin7 Build directory root: /Users/sge/haskell/hmake-3.09/targets (exists) Object files build in: /Users/sge/haskell/hmake-3.09/targets/powerpc-Darwin7 (exists) Executables and libs: /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7 (created) I have guessed you will build hmake with: ghc Testing for the curses library: -lncurses (detected) Testing for the readline library: -lreadline (detected) Executables need .exe suffix? no (detected) Found /usr/bin/true not /bin/true Adding Makefile config script to /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7... Adding build scripts for hmake, hmake-config, and hi to /Users/sge/haskell/hmake-3.09/script... Updating targets/powerpc-Darwin7/hmake3.config... Saving current configuration in targets/powerpc-Darwin7/config.cache Done. Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ Thanks, Steve ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level state debate on the wiki
On Thu, Dec 02, 2004 at 09:08:21AM +, Keean Schupke wrote: Ben Rudiak-Gould wrote: Just a small comment on the Wiki page... it says Several real-life examples of pure haskell code which needs fast global variables to either be implemented efficiently or statically guarantee their invariants are given in http://www.haskell.org//pipermail/haskell/2004-November/014929.html; The first example is that of randomIO - not implementable in Haskell, however the function, randoms :: RandomGen g = g - [a], is (and is probably more idomatic haskell anyway). Yes. There are lots of ways to do things without global variables, that was never in doubt. However randomIO is a part of the haskell standard. Why is it not (efficiently) implementable in haskell? There is no particular reason it should not be. it should optimize to exactly about 5 instructions to run the linear congruence algorithm on a static location in memory. The second example Unique, can be implemented: getUniqueSupply = do a - newIORef 0 return (nextUnique a) where nextUnqiue n = do x - readIORef n writeIORef n (x+1) return x Which should be just as fast as the global version, and all you do is pass the 'unique' supply around... you can even generate a lazy list of unqiues which can be used outside the IO monad. Again the disadvantage is that you can have multiple unique supplies and you could use the wrong one... (which is an advantage in my opinion, as it increases flexibility and reuse of the code). Yes, this would be as fast as the global version*, but it implements something else. The entire point of Data.Unique is that one can consider the unique supply as part of the world, just like you consider the filesystem, the screen, the network, various OS routines, etc as part of the world. This should be implementable efficiently, after all, you can store the counter in a file in /tmp, or just create a stub C file to do it, so it is obviously not a bad thing to allow, it is already allowed, it just needs to be able to done efficiently or people will resort to unsafe hacks like unsafePerformIO which is a serious impediment to aggressive compiler optimizations and a plauge on the mathematical semantics of the intermediate language. The same applies to the AtomHash, it can be implemented just as effieciently without globals... The only difference appears to be the supposed ability of globals stopping the programmer using an alternate Hash... but of course there is nothing stopping the programmer using the wrong global at all! (In other words it seems just as easy to access the wrong top-level name as to pass the wrong parameter). No, because then it would not typecheck. the whole point of Atom.hs is that the only way to generate values of type 'Atom' is to go through the single unique hash table. Hence the static guarentee that there is always an isomorphism between everything of type 'Atom' and everything of type 'String' in the system. This is only made possible by the modules ability to hide access to routines which could be used to break the invarient (such as the raw global hash). This is obviously a very important invarient! Let us please not confuse the many philosophical issues against global variables in design which I wholeheartily agree with, with what the global variables proposal is meant to achieve. It is for use at the very lowest level of the libraries. i.e. not to be used by the average person. They are for Atom tables, memoization, anti-memoization, I have desires to move some of the runtime stable/weak pointer infrastructure out of being magic implemented by the runtime, to being implemented in haskell itself, this requires the global hash of stablepointers to be implementable directly. Ghc itself is getting rid of global variables AS SEEN BY THE PROGRAMMER but many libraries still NEED them inside to do their clever memoization tricks and fast strings which are required to make ghc usable at all. Really, you should not be opposed to them unless you are also opposed to the FFI. At some level, deep inside the libraries, this functionality is needed, just like the FFI. it is even needed to implement the type indexed execution context proposals. Exposing the fact there is global state will still be a bad idea, their usage will be hidden by pure interfaces by good programers, just like unsafePerformIO or uses of the ST monad are done now. A module which provides observable global state, but does not let you parameterize over it is bad form. For example randomIO has implicit global state, but you can use the parameterized versions such as randoms. unlike Random Atom.hs DOES NOT HAVE IMPLICIT GLOBAL STATE. A perfectly acceptable implementation would be toAtom = fromAtom = id. This is why Atom does not need to be parameterized over its global state. the fact it is used is completly abstracted away because it is an
Re: [Haskell-cafe] problem building hmake on Mac OS X
Steven Elkins [EMAIL PROTECTED] writes:
I'm trying to build hmake on version 10.3.6 of Mac OS,
GHCSYM=#pragma GCC set_debug_pwd /Users/sge/haskell/hmake-3.09
602
Thanks for the bug report - another MacOS user has already reported
it and supplied a patch (attached). Apparently Apple's version of
gcc always inserts that nasty pragma line.
Regards,
Malcolm
Index: script/confhc
===
RCS file: /home/cvs/root/nhc98/script/confhc,v
retrieving revision 1.41
diff -u -r1.41 confhc
--- script/confhc 12 Nov 2004 17:53:45 - 1.41
+++ script/confhc 2 Dec 2004 10:35:06 -
@@ -65,8 +65,9 @@
# Now look for GHC. Determining the version number here is due to Simon
Marlow.
ghcsym () {
echo __GLASGOW_HASKELL__ ghcsym.hs;
- $1 -E -cpp -optP-P ghcsym.hs -o $2;
- rm -f ghcsym.hs;
+ $1 -E -cpp -optP-P ghcsym.hs -o ghcsym.out;
+ grep -e '^[0-9]*$' ghcsym.out $2;
+ rm -f ghcsym.hs ghcsym.out;
}
echo -n Looking for ghc...
if which ghc /dev/null 21
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level state debate on the wiki
Hi John, I am not objecting to the top-level TWIs anymore - since I realised contexts can be provided by wrapping the MVar or IORef modules. I just thought the wiki misrepresented the calims of your examples (or maybe the claims are a little exaggerated)... As far as I can tell adding top level TWIs will change nothing as they provide no guarantees of uniqueness. As nothing changes (exept you don't have to pass them around) - I have nothing to object to in this proposal ... although option 2b from the wiki would be my favourate. John Meacham wrote: Yes. There are lots of ways to do things without global variables, that was never in doubt. However randomIO is a part of the haskell standard. Why is it not (efficiently) implementable in haskell? There is no particular reason it should not be. it should optimize to exactly about 5 instructions to run the linear congruence algorithm on a static location in memory. The comment was really about the 'introductory' line in the wiki, which seemed to me to be stating there are efficiecy reasons for using global variables (false, as the examples I gave show) and that they provide some static guarantees (false, as I can replace the MVar library and break the unique property - so it is not a static guarantee - It just makes it a little more convoluted to get around)... As for randomIO not being implementable in Haskell, this is true, but it is no more efficient than passing a random sequence generator: getRandomSource = do a - newIORef 0 return (nextRandom a) where nextRandom n = do -- where g and f are the generator functions x - readIORef n writeIORef n (g x) return (f x) Yes, this would be as fast as the global version*, but it implements something else. The entire point of Data.Unique is that one can consider the unique supply as part of the world, just like you consider the filesystem, the screen, the network, various OS routines, etc as part of the world. Yes, but not necessarily unique. I may have more than one keyboard... Infact any assumption that a resource is unique is normally a bad one - for example windows only supporting one display - they probably had to rewrite a lot of code using globals when they wanted to support multi-headed machines. This should be implementable efficiently, after all, you can store the counter in a file in /tmp, or just create a stub C file to do it, so it is obviously not a bad thing to allow, it is already allowed, it just needs to be able to done efficiently or people will resort to unsafe hacks like unsafePerformIO which is a serious impediment to aggressive compiler optimizations and a plauge on the mathematical semantics of the intermediate language. I agree here - I can always change the filesystem with a OS call (like chroot) and I can swap the top-level TWI context with a wrapper module around the MVar/IORef module. No, because then it would not typecheck. the whole point of Atom.hs is that the only way to generate values of type 'Atom' is to go through the single unique hash table. Hence the static guarentee that there is always an isomorphism between everything of type 'Atom' and everything of type 'String' in the system. This is only made possible by the modules ability to hide access to routines which could be used to break the invarient (such as the raw global hash). This is obviously a very important invarient! But this can be broken with a wrapper module around IORef that lets me change contexts... so it is the same in reality, just it requires a little more thought to get round the guarantee. Let us please not confuse the many philosophical issues against global variables in design which I wholeheartily agree with, with what the global variables proposal is meant to achieve. It is for use at the very lowest level of the libraries. i.e. not to be used by the average person. They are for Atom tables, memoization, anti-memoization, I have desires to move some of the runtime stable/weak pointer infrastructure out of being magic implemented by the runtime, to being implemented in haskell itself, this requires the global hash of stablepointers to be implementable directly. Ghc itself is getting rid of global variables AS SEEN BY THE PROGRAMMER but many libraries still NEED them inside to do their clever memoization tricks and fast strings which are required to make ghc usable at all. Really, you should not be opposed to them unless you are also opposed to the FFI. At some level, deep inside the libraries, this functionality is needed, just like the FFI. it is even needed to implement the type indexed execution context proposals. No as I said, my objection was to the summery line which claimed globals necessary for speed or static guarantees - both claims are false (and I don't think you claimed as such in the examples - so it is only in regards to the wiki entry) Exposing the fact there is global state will still be a bad idea,
Re: [Haskell-cafe] Top-level state debate on the wiki
Nice summary. What I think is missing is an explanation of when you would want this feature (and when you wouldn't, more importantly). Here is the kind of platonic dialogue that summarises my limited understanding: [..dialogue snipped..] This is good, and is the sort of thing that should go on the Wiki, for people to edit and discuss and take issue with. Feel free to add it to the existing page, or create a new one and link to it. The Wiki belongs to all Haskellers! --KW 8-) ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building hmake on Mac OS X
Hi Steve, I see that Malcolm Wallace has already answered your question, but you might be interested in some of the other haskell tools for OS X supported under darwinports. See http://darwinports.opendarwin.org hmake is supported, as well as a the new haskell-mode for emacs and a bunch of other stuff (e.g. alex, happy, hat, buddha, haskelldb). I support most of the tools, so feel free to ask questions. Best Wishes, Greg On Dec 2, 2004, at 5:05 AM, Steven Elkins wrote: Hello everyone, I'm trying to build hmake on version 10.3.6 of Mac OS, having installed the ghc 6.2.2 dmg I found on haskell.org, but I'm encountering the following problem: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ make cd src/hmake; make HC=ghc all config /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7/config:9: *** missing separator. Stop. make: *** [targets/powerpc-Darwin7/hmake-ghc] Error 2 Here's lib/powerpc-Darwin7/config: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ cat lib/powerpc-Darwin7/config BUILDWITH=ghc BUILDOPTS= INSTALLVER=3.09 (2004-11-13) INSTALLINFO=config: powerpc-Darwin7/ by [EMAIL PROTECTED] on Thu Dec 2 04:43:46 EST 2004 BUILDBASEDIR=/Users/sge/haskell/hmake-3.09/targets READLINE=-DUSE_READLINE=1 -lreadline EXE= GHCSYM=#pragma GCC set_debug_pwd /Users/sge/haskell/hmake-3.09 602 TRUE=/usr/bin/true In case Gmail wraps this, line 9 has the oracular '602'. Finally, here's the ./configure output: Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ ./configure --prefix=/usr/local Configuring for hmake... [ 3.09 (2004-11-13) ] Looking for already-installed Haskell compilers: Looking for hbc... (not found) Note: LMLDIR/HBCDIR variables must be set to enable detection of hbc. Looking for ghc... found 6.2.2 Looking for nhc98... (not found) I am guessing that you want to use ghc to build hmake. Now I'm creating targets/powerpc-Darwin7/hmake3.config for your installation. Done. Configuration report for hmake. (You can re-run configure to change settings before proceeding.) You wish (eventually) to install the following components in these locations: (Installation directories are not created/checked at this stage.) Final install root: /usr/local hmake binaries: /usr/local/lib/hmake/powerpc-Darwin7 Scripts: /usr/local/bin Man pages:/usr/local/man/man1 Now we check/create your build directories: Config directory: targets/powerpc-Darwin7 Build directory root: /Users/sge/haskell/hmake-3.09/targets (exists) Object files build in: /Users/sge/haskell/hmake-3.09/targets/powerpc-Darwin7 (exists) Executables and libs: /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7 (created) I have guessed you will build hmake with: ghc Testing for the curses library: -lncurses (detected) Testing for the readline library: -lreadline (detected) Executables need .exe suffix? no (detected) Found /usr/bin/true not /bin/true Adding Makefile config script to /Users/sge/haskell/hmake-3.09/lib/powerpc-Darwin7... Adding build scripts for hmake, hmake-config, and hi to /Users/sge/haskell/hmake-3.09/script... Updating targets/powerpc-Darwin7/hmake3.config... Saving current configuration in targets/powerpc-Darwin7/config.cache Done. Steven-Elkins-Computer:~/haskell/hmake-3.09 sge$ Thanks, Steve ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level state debate on the wiki
With regards to the following... There are cases in which this parameterization costs convenience and gains nothing -- for example, the standard library function (randomIO :: Random a = IO a) cannot be implemented in Haskell without the unsafePerformIO hack, yet there's nothing semantically objectionable about it. Worse, we may weaken type checking by the translation, while gaining nothing: for example, the interface below cannot provide static guarantees like a == b = fromAtom a == fromAtom b if toAtom is parameterized by an atom space. Can we not make this guarantee with multiple Atom-spaces if we use the same local universal quantification trick used on the ST monad? IE add a type parameter 's' to the type of Atom? Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level state debate on the wiki
On Thu, Dec 02, 2004 at 10:53:57AM +, Keean Schupke wrote: Hi John, I am not objecting to the top-level TWIs anymore - since I realised contexts can be provided by wrapping the MVar or IORef modules. I just thought the wiki misrepresented the calims of your examples (or maybe the claims are a little exaggerated)... Yeah, I apologize, my comments wern't directed at you in particular, I was sort of just responding to the whole thread in batch mode. Yes. There are lots of ways to do things without global variables, that was never in doubt. However randomIO is a part of the haskell standard. Why is it not (efficiently) implementable in haskell? There is no particular reason it should not be. it should optimize to exactly about 5 instructions to run the linear congruence algorithm on a static location in memory. The comment was really about the 'introductory' line in the wiki, which seemed to me to be stating there are efficiecy reasons for using global variables (false, as the examples I gave show) That example solves a different problem, I was never claiming that there wern't efficient ways to solve the unique producer problem in general, just no efficient way to provide the interface as given in Data.Unique, a top level declaration of type 'IO Int'. (false, as I can replace the MVar library and break the unique property - so it is not a static guarantee - It just makes it a little more convoluted to get around)... If you are allowed to replace code at will then nothing anywhere is guarenteed in haskell :) I mean you could replace head with head = error No head for you. and a lot of libraries would break. It would be the responsibility of anyone replacing key system libraries to guarentee they are observationally equivalant to what their users expect. For users of Atom, you still have strong static guarentees at least as strong as any other guarentees in haskell. So, an implementation of MVar which randomly cloned state would not break the static guarentees of Atom as much as it would break the guarentees of MVar and hence anything that relys on it. As for randomIO not being implementable in Haskell, this is true, but it is no more efficient than passing a random sequence generator: getRandomSource = do a - newIORef 0 return (nextRandom a) where nextRandom n = do -- where g and f are the generator functions x - readIORef n writeIORef n (g x) return (f x) Yes. but that has the same problem as your other example. it is a different interface than the one we want. If we want to pass around the state we can use many of the other routines in Random. If we want to extend the world with the standard generator (which is perfectly reasonable, and useful enough to make it into the standard haskell libraries), we are out of luck. Yes, this would be as fast as the global version*, but it implements something else. The entire point of Data.Unique is that one can consider the unique supply as part of the world, just like you consider the filesystem, the screen, the network, various OS routines, etc as part of the world. Yes, but not necessarily unique. I may have more than one keyboard... Infact any assumption that a resource is unique is normally a bad one - for example windows only supporting one display - they probably had to rewrite a lot of code using globals when they wanted to support multi-headed machines. Hrm? This is unrelated, I never claimed anything about uniqueness, just that the filesystem, screen[s], keyboard[s], etc.. are part of the world. TWIs are to extending the world in a more efficient way than writing to a file and a more safe way than using unsafePerformIO. unique identitfiers are one example of a use of them (assuming you have appropriate library functions to allow this use). This should be implementable efficiently, after all, you can store the counter in a file in /tmp, or just create a stub C file to do it, so it is obviously not a bad thing to allow, it is already allowed, it just needs to be able to done efficiently or people will resort to unsafe hacks like unsafePerformIO which is a serious impediment to aggressive compiler optimizations and a plauge on the mathematical semantics of the intermediate language. I agree here - I can always change the filesystem with a OS call (like chroot) and I can swap the top-level TWI context with a wrapper module around the MVar/IORef module. Yeah, I imagine this functionality would be useful to implement debuggers like 'hat' where you need to collect 'meta-information' about a run of the program. again, I don't see the ability to replace library calls like IORef as a weakness in the guarentees provided by stuff that uses them, as it is up to the replacer of the libraries to do the right thing. No, because then it would not typecheck. the whole point of Atom.hs is that the only way
Re: [Haskell-cafe] Top-level state debate on the wiki
Just a few minor nitpicks... mainly about the necessity of using certain APIs, however I think we are in general agreement... Keean. John Meacham wrote: That example solves a different problem, I was never claiming that there wern't efficient ways to solve the unique producer problem in general, just no efficient way to provide the interface as given in Data.Unique, a top level declaration of type 'IO Int'. My argument would be program in the idomatic style of the language, rather than change the language. In other words it is not necessary to implement that API, it is a preference. If you are allowed to replace code at will then nothing anywhere is guarenteed in haskell :) I mean you could replace head with head = error No head for you. and a lot of libraries would break. I am only talking about substitutimg modules... you can simply feed ghc a different search path with -i, and insert a wrapper around the module. My point was it is a possible way to take a third party library that supports only one global context and get it to support many contexts without changing a single line of code in the library itself, and this is a good thing IMHO. Yes. but that has the same problem as your other example. it is a different interface than the one we want. If we want to pass around the state we can use many of the other routines in Random. If we want to extend the world with the standard generator (which is perfectly reasonable, and useful enough to make it into the standard haskell libraries), we are out of luck. But you can use this different interface - it may not be the one you would like - but it does the job. My point was it is not necessary to have a generator with the API you gave, again it is a preference. Yeah, I imagine this functionality would be useful to implement debuggers like 'hat' where you need to collect 'meta-information' about a run of the program. again, I don't see the ability to replace library calls like IORef as a weakness in the guarentees provided by stuff that uses them, as it is up to the replacer of the libraries to do the right thing. Yes, I think it is a sign of good modularity. Keean. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Top-level state debate on the wiki
Keean Schupke wrote: Ben Rudiak-Gould wrote: [...] Just a small comment on the Wiki page... it says Several real-life examples of pure haskell code which needs fast global variables to either be implemented efficiently or statically guarantee their invariants are given in http://www.haskell.org//pipermail/haskell/2004-November/014929.html; I don't know if this post was meant specifically for me, but in any case I didn't write the sentence quoted above. Other people have already added material to my original wiki page, and I encourage you to do the same if you disagree with what's there right now. To everyone who's posted in this thread: I think you're misunderstanding what I meant by the phrase on the wiki. :-) My hope was/is that this whole debate /moves/ to the wiki exclusively. My impression is that the mailing-list debate has made no progress for some time (weeks) and almost all of the traffic now consists of weekly or daily repetitions of the same old points and counterpoints. This is a sign that the time has come to move to a discussion format that doesn't require reiteration. -- Ben ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Non-technical Haskell question
Simon Peyton-Jones wrote: | I also have a very small start on a haskell for hackers (hackers in | the non-evil sense) sort of document. One this doesn't ignore I/O as | hard or unimportant. I/O in Haskell doesn't suck. It's just that a | lot of people in the community don't have it as a high priority, I | think. As a shameless plug, have you tried Tackling the awkward squad?. Indeed I/O in Haskell doesn't suck. http://research.microsoft.com/%7Esimonpj/papers/marktoberdorf Well I thought I had a good grasp of Haskell I/O, but I read that paper anyway and found many interesting things (exceptions and Concurrent Haskell are both new to me, and the FFI is something I've only touched on briefly). I'd recommend that to others struggling with the IO monad; I wish I'd read it three years ago! Thanks ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building hmake on Mac OS X
On Thu, 2 Dec 2004 10:38:16 +, Malcolm Wallace [EMAIL PROTECTED] wrote: Thanks for the bug report - another MacOS user has already reported it and supplied a patch (attached). Many thanks, the patch did the trick. Steve ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem building hmake on Mac OS X
Thanks for reminding me of DarwinPorts. I've been meaning to look at it. The haskell tools are more complete than Fink's. I didn't see the new Emacs mode you mentioned when I looked earlier today (and now I'm getting Parse error: parse error in /Library/WebServer/Documents/projects/darwinports/ports.php on line 126 when I try to visit the ports page, but never mind that). Is it part of something, or did I just miss it? Thanks, Steve On Thu, 2 Dec 2004 06:35:15 -0500, Gregory Wright [EMAIL PROTECTED] wrote: Hi Steve, I see that Malcolm Wallace has already answered your question, but you might be interested in some of the other haskell tools for OS X supported under darwinports. See http://darwinports.opendarwin.org hmake is supported, as well as a the new haskell-mode for emacs and a bunch of other stuff (e.g. alex, happy, hat, buddha, haskelldb). I support most of the tools, so feel free to ask questions. Best Wishes, Greg ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-technical Haskell question
I think you may be asking the wrong question. As one of the rank and file and fairly new to Haskell (less then a month) I can tell you that there is a growing awareness of functional programming and that it offers different paradigms to work with. I think the more important question is - is Haskell ready? So far, from the perspective of a newbie, I would say no. The documentation is sparse and confusing, the standard libraries seem incomplete and how complitaion and linking is handled feels antiquated. I mean I think its a really cool idea, and I'm having fun learning it. But I would be hard pressed to come up with a justification to introduce this into our business environment. Jason GoldPython wrote: Hi, all, I'm new to the Cafe, but not to Haskell (experimented with it on and off on a small scale over the last 5 or 6 years and enjoy the language quite a lot) and had more of a political question and wanted to see what people thought: Has anyone tried presenting the language to the average rank and file programming community? If so, was it successful? If not, is there interest in doing so? By rank and file I mean, outside of the acedemic world where a large number of the programmers I see have very little math background. This would be the typical commercial Visual Basic crowd and the like. Thanks, Will Collum ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-technical Haskell question
On 3 Dec 2004, at 03:48, Jason Bailey wrote: As one of the rank and file and fairly new to Haskell (less then a month) I can tell you that there is a growing awareness of functional programming and that it offers different paradigms to work with. That's good to hear. The documentation is sparse and confusing, Agreed. The hierarchical library documentation is poor in many places. the standard libraries seem incomplete Compared to perl or java? Yes, absolutely. Perl and Java both have enormous libraries of software available, and both have taken years and years to reach the current state. Compared to C/C++ (which are both popular 'real world' languages, of course) I think haskell isn't doing so badly. and how complitaion and linking is handled feels antiquated. Can you be more specific here? Jules ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
