Fwd: Hugs on Mac with CW6 ? ... and Haskell Graphics Lib?
Hello, I was wondering whether you know if anyone has gotten Hugs to compile on Mac OS 9, using CodeWarrior 6. I am wanting to get to know Haskell a little, and I have a copy of Paul Hudak's book "The Haskell School of Expression", so I thought it would be cool to run the book's examples on my Mac at home. Unfortunately, I could not find any Mac port of the Haskell Graphics Library. So I decided it would make sense to try to compile Hugs on the Mac. Though I have known C for decades (worked at Sun for 10 years, now Apple for just over five), I'm a novice at using Codewarrior and at Mac GUI programming in C. It looks like Metrowerks may have changed some things about the SIOUX interface and/or how stdarg.h works, in between CW 5 and CW 6. (I deduce this from my feeble attempts at compiling and debugging a plain Hugs with CW 6.) Once I can get a plain Hugs working with CW 6, I'm hoping to try to figure out how to get it to interface to C, so I could supply something like the Haskell Graphics Library and link it in with Hugs. So anyway, I have some specific questions: -- has anyone gotten Hugs to compile on Mac OS 9 under CW 6? -- has anyone gotten Hugs+HGL to work on any Mac (OS 9 or OS X)? -- where should I look to figure out how the mac version of Hugs wants to interface with a C-based library? -- would it be easier to work with GHC or HBC instead of Hugs? (High speed is not a big concern of mine at the moment, I just want to learn and be able to play around with Haskell.) Thanks in advance for any guidance you might be able to provide. -- -- Doug Landauer landauer@scruznet.com (home) landauer@apple.com (work)
[Hugs Users removed from Cc list. Messages about machine support traditionally go to hugs bugs only. Also, since hugs-bugs members are supposed to be in hugs-users also, listing both is redundant.]
Unfortunately, I could not find any Mac port of the Haskell Graphics Library.
I'm afraid there isn't one. I have access to Unix and to Windows but not to a Mac. (Also I don't know the Mac API.)
Once I can get a plain Hugs working with CW 6, I'm hoping to try to figure out how to get it to interface to C, so I could supply something like the Haskell Graphics Library and link it in with Hugs.
Let me describe a few major steps in being able to write (or port) something like the HGL for the Mac: 1) Get Hugs working (obviously) 2) Learn how to use one of the many Hugs Foreign Function Interfaces (FFIs) on the Mac. Choices: 1) Directly modify builtin.c in the Hugs distribution. Tedious, error-prone, not recommended. 2) Use GreenCard (http://www.dcs.gla.ac.uk/fp/software/green-card/) Stable, simple, limited level of support (none?) Requires you to find out how to build the Mac equivalent of shared libraries (Unix terminology) or DLLs (Windows terminology). (Looking at the Hugs sources, it appears that the answer is a .pef file and that someone has figured this out before - hopefully someone can send instructions in response to this message.) 3) Use H/Direct (http://haskell.cs.yale.edu/haskellscript/hdirect.html) Easy to use if you already have a COM/IDL specification of the API you want to use. It's not clear whether it's still supported since the above page says the real home page is at: http://www.dcs.gla.ac.uk/fp/software/hdirect which is a broken link. 4) Use the FFI standard (http://haskell.cs.yale.edu/definition/ffi/) possibly in conjunction with some of the ffi tools/libraries that have come out such as Manuel Chakravaty's C->Haskell library (http://www.cse.unsw.edu.au/~chak/haskell/c2hs/) This is the preferred option. There's just one small problem that I'll expand on below. 5) Consult Haskell.org (http://haskell.org/libraries/#interfacing) Of these, I strongly recommend (4) with (2) as a second choice. The one small problem with (4) is that the official Hugs distribution does not support the FFI standard. However, there is an unofficial Hugs distribution which does support it. You can download it from my home page: http://www.cs.utah.edu/~reid/tmp/hugs98-ffi-03122000.tgz If you need to use foreign export dynamic, you will need to write a small machine code stub for your architecture. 3) Learn how to write simple graphical programs in C for the Mac. By simple I mean how to do things like: Hello World (where the text appears centred on a window). A simple drawing program that puts a black pixel on the screen if the mouse button is depressed. Responds to simple keyboard input. Responds to periodic and/or one-shot timers. 4) Use your choice of FFI to translate your simple C programs into Haskell. 5) Contact me for help on understanding the code in the Hugs Graphics Library (or for hints on how to produce something equivalent). (There's someone else trying to port the HGL to GHC so a 3-way discussion might arise.) [The above list could take a while to work through and might be best tackled by a team of people rather than just one person who is new to Haskell. The HGL and all the associated tools, libraries and techniques I had to develop to write it was spread out over a period of about 5 years.]
-- would it be easier to work with GHC or HBC instead of Hugs?
It would be easier in that both have mature implementations of the ffi. However, I don't know if either of them has been ported to the Mac yet. If the answer is no, I think it would be significantly easier to work with Hugs. (This belief is based on lots of experience with Hugs and GHC. I know very little about HBC.) -- Alastair Reid
At 13:43 -0700 0-12-07, Alastair Reid wrote:
2) Use GreenCard (http://www.dcs.gla.ac.uk/fp/software/green-card/) Stable, simple, limited level of support (none?) Requires you to find out how to build the Mac equivalent of shared libraries (Unix terminology) or DLLs (Windows terminology). (Looking at the Hugs sources, it appears that the answer is a .pef file and that someone has figured this out before - hopefully someone can send instructions in response to this message.)
I'm afraid I was the guy who put that "pef" stuff in, which does not directly related to DLL. ("PEF" = portable executable format or something is a slimmed down variation of IBM's XCOFF format for object files that contains names admitting various types of linking -- possibly dynamic and solving the fragile base class problem.) Dynamic loading under pre-MacOS X though is very complicated, especially if the loading should take place while your program is running (and not only under startup). So I eventually gave up on that, because I didn't have time for it. By contrast DLL under MacOS X seems to be automatic -- one simply requests the functions in the source code just as any statically linked function, and the OS loads them "lazily" at need when required. So, by contrast, anything that can be done with DLL seems to be recommended under MacOS X. Hans Aberg
By contrast DLL under MacOS X seems to be automatic -- one simply requests the functions in the source code just as any statically linked function, and the OS loads them "lazily" at need when required. So, by contrast, anything that can be done with DLL seems to be recommended under MacOS X.
This isn't quite what Hugs needs. Hugs needs functionality equivalent to dl_open on unix.
From memory and with some simplification:
handle dl_open(char*) loads a shared library file dl_lookup(handle,char*) looks up a name in a loaded shared library dl_close(handle) closes a shared library Loading has to be explicit because it is done in response to the Hugs user loading a Haskell file that requires a shared library. -- Alastair
At 11:54 -0700 0-12-08, Alastair Reid wrote:
By contrast DLL under MacOS X seems to be automatic -- one simply requests the functions in the source code just as any statically linked function, and the OS loads them "lazily" at need when required. So, by contrast, anything that can be done with DLL seems to be recommended under MacOS X.
This isn't quite what Hugs needs. Hugs needs functionality equivalent to dl_open on unix.
From memory and with some simplification:
handle dl_open(char*) loads a shared library file dl_lookup(handle,char*) looks up a name in a loaded shared library dl_close(handle) closes a shared library
Loading has to be explicit because it is done in response to the Hugs user loading a Haskell file that requires a shared library.
The document http://developer.apple.com/techpubs/macosx/SystemOverview/SystemOverview.pdf page 109-110 describes this automatic loading. One might surmise that explicit loading of libraries & names is also available, but it is not described there. -- I think that the calle them "plug-ins", and can be loaded at any time, loc. cit. p. 22, even though it is not described how that is done there. It is said on p 182 that MacOS X has a dyld, dynamic link editor, a library manager for processes based on Mach-O object files, so it should somehow be possible. Hans Aberg
Hugs needs functionality equivalent to dl_open on unix.
From memory and with some simplification:
handle dl_open(char*) loads a shared library file dl_lookup(handle,char*) looks up a name in a loaded shared library dl_close(handle) closes a shared library
It sure would be nice if Apple would provide an implementation of this relatively common API. It shouldn't be that difficult to extract this functionality from the more comprehensive bundle services that are a part of Mac OS X. I think the relevant documentation might be found somewhere near here: http://developer.apple.com/techpubs/macosx/CoreFoundation/BundleServices and in particular this part: http://developer.apple.com/techpubs/macosx/CoreFoundation/BundleServices/CFB... -- Doug
participants (4)
-
Alastair Reid -
Doug Landauer -
Doug Landauer -
Hans Aberg