- Haskell - Haskell.org

Re: UTF-8 library
by Ashley Yakeley 07 Aug '02

07 Aug '02

At 2002-08-07 03:03, Axel Simon wrote: >> Text encoded with ISO 8859-1 or UTF-8 is octets. If you want to use >> CChars, you should then subsequently convert the Word8s into CChars. >Then I hope there is no C implementation where char is less than 8 bits >long. There may or may not be. Squeezing in octets from ISO 8859-1 encoding is a problem you'll have to deal with either way, and is entirely separate from the text encoding process. -- Ashley Yakeley, Seattle WA

1 0

Re: Efficiency of list indices in definitions
by oleg＠pobox.com 07 Aug '02

07 Aug '02

Carl McTague wrote: > finAuDeterminize :: (Ord l) => FinAu l -> FinAu [l] > finAuDeterminize startStates = [f startStates] > where f :: (Ord l) => [FaState l] -> FaState [l] > f states = FaState label' acceptQ' trans' > where label' = sort (map label states) > acceptQ' = or (map acceptQ states) > trans' = map (singleton.f.concat) (transpose (map trans states)) > singleton a = [a] > Now, we get to the heart of my question. This definition is quite > lovely, recursive and lazy, but it doesn't actually capture the > recurrent structure of the resulting automata. That is, if we were to > compute: > finAuAcceptStringQ (finAuDeterminize dom18) somestring > then finAuDeterminize would keep spinning out, generating more and > more states, which would actually be equivalent (and, have identical > state labels). To prevent such a behavior we ought to keep track of the states that we have already computed. Before getting to the solution, I'd like to take the liberty to modify your definition for the FSM to improve readability (at the expense of efficiency). I'd like to be able to print automata, to see what exactly I have determinized. data FaState l = FaState {label :: l, acceptQ :: Bool, trans :: [[l]]} deriving(Eq,Show) -- states start states data FA l = FA [(l,FaState l)] [l] deriving Show The transition function is now the list of labels rather than the list of states. A naive NFA recognizing a sample 0*(0(0+1)*)* can be written as dom18 = FA [(1,one), (2,two)] [1] where one = FaState 1 True [[1,2],[]] two = FaState 2 True [[2,1],[2,1]] (BTW, I had trouble with the automaton in the original article. That NFA recognized [1], which it should not). The acceptance function can be written as finAuAcceptStringQ :: (Eq l) => FA l -> [Int] -> Bool finAuAcceptStringQ (FA all_states start_labels) str = or [acceptP (locate_state l) str | l <- start_labels] where locate_state l = let (Just state) = lookup l all_states in state acceptP (FaState _ acceptQ _) [] = acceptQ acceptP (FaState _ _ trans) (a:as) = or [ acceptP (locate_state l) as | l <- followerStates ] where followerStates = if a > (length trans) - 1 then [] else trans!!a The determinizer can then be written as follows: finAuDeterminize (FA all_states start_labels) = FA all_states' [start_label'] where -- [NFA_labels] -> DFA_labels det_labels = sort . nub start_label' = det_labels start_labels -- DFA states all_states' = build_states [start_label'] [] -- build_states labels seen_labels -- lazily builds the list of DFA states. 'labels' is the list -- of labels for the states to build. seen_labels are the labels -- of the states we have built already build_states [] seen_labels = [] build_states (l:labels) seen_labels = if l `elem` seen_labels then -- already built DFA state l build_states labels seen_labels else really_build l labels seen_labels -- Build a DFA state with a label 'dfa_label' and return a list -- of the constructed state and a promise to build the follower states really_build dfa_label labels seen_labels = (dfa_label,dfa_state): build_states new_labels (dfa_label:seen_labels) where dfa_state = FaState dfa_label acceptQ' trans' locate_state l = let (Just state) = lookup l all_states in state nfa_states = map locate_state dfa_label acceptQ' = or (map acceptQ nfa_states) trans' = map ((:[]).det_labels.concat) $ transpose $ map trans nfa_states new_labels = (concat trans') ++ labels test1' = finAuAcceptStringQ (finAuDeterminize dom18) [0,1,0,1] test2' = finAuAcceptStringQ (finAuDeterminize dom18) [1,0] The states of the output DFA are built lazily. Each state is constructed only once. To see that equivalent states are not duplicated, we can check the result of determinizing the dom18: finAuDeterminize dom18 prints FA [([1], FaState{label=[1], acceptQ=True, trans=[[[1,2]],[[]]]}), ([1,2], FaState{label=[1,2],acceptQ=True, trans=[[[1,2]],[[1,2]]]}), ([], FaState{label=[], acceptQ=False,trans=[]})] [[1]] -- the starting state which is indeed a DFA (and so happens, the minimal one).

4 4

ANNOUNCE: Haskell mode for Vim (release 0.1)
by Claus Reinke 06 Aug '02

06 Aug '02

Dear Haskellers, one result of our recent survey on Haskell editing habits was that local/inhouse/custom hacks should be shared more widely. In this sense, I've made my own Vim customizations for Haskell available as a kind of Haskell mode for Vim, with some minimal documentation. It consists of two files (plugin script and helpfile), to be used in addition to Vim's standard Haskell syntax files (see helpfile and webpage for more info). The Vim Haskell mode was mostly written before the survey results came in and so doesn't include many of the interesting suggestions made there. It does, however, borrow one or two ideas from the Emacs Haskell mode, and if there's enough interest, I'll keep updating the Vim version;-) http://www.cs.ukc.ac.uk/people/staff/cr3/toolbox/haskell/Vim/ [The web page includes both a hugs.vim and a ghci.vim, but the latter isn't fully functional yet, so I recommend to use the former until the next release] Note that, while one purpose of writing it was to get to know Vim's facilities for scripting and integrating external tools (such as refactorers), this is more of a hack than a proper syntax-aware editing tool. For the latter, you'll have to wait until our refactoring project puts out first prototypes. That will take a while, though, and in the meantime, the Haskell modes for Vim/Emacs/?? can be stretched a little bit further before it gets ridiculous (don't want to write a Haskell frontend in Vim Script!-). Happy Haskell Vimming (and let me know what you think about it;-)! Claus

1 0

SURVEY - Haskell editing (summary)
by Claus Reinke 06 Aug '02

06 Aug '02

As promised, here comes the summary of our survey results. Given the low number of responses, it is more anecdotical evidence than representative statistics, but thanks to the individual comments, it will be helpful for our project, and some of you may find the summary interesting. As everyone was invited to contribute, we'll assume that we've got the confessions of those Haskell hackers who care!-) Thanks to everyone who contributed, Claus "Refactoring Functional Programs" http://www.cs.ukc.ac.uk/research/groups/tcs/fp/Refactor/ ----------July 2002-----(summary)-------- SURVEY - Haskell editing In total, we got 45 responses. Not every response addressed all questions, and often there were several answers per response and question. So there's no summing up of sensible percentages, but the variety of answers (the questions only outlined possible answers, thus inviting keyword-style, but otherwise free-form responses), and some clear tendencies -amid the small selection of responses we got- are interesting. The following summary roughly lists each answer together with the number of times it was mentioned in different responses, sometimes accompanied by typical comments. Editor comments, based on summaries of the survey responses, follow in separate sections after each question/answer block (the editor's response is not included in the survey). [Proportional font won't be a good idea for the following] --------------------------------- 1. When developing Haskell programs, ----------------------------------- which OS-platforms do you work on? Linux: 43 (2.2/2.4,redhat 6.1/7.1/7.2, debian testing/unstable/woody, mandrake) Solaris: 17 SunOS: 3 Windows98: 1 Windows2000: 3 Win32: 2 Cygwin: 2 FreeBSD: 5 MacOS X: 3 IRIX: 1 --Comments Unix-style operating systems clearly dominate here, even more so since many of the non-unix entries stem from multi-OS developers, who use some variant of unix or windows as their main development platform, and several other OSs for production, to test portability / compatibility, or just because of their working environments. Given the small number of survey responses, one should keep in mind that this indicates a bias in the responses that may or may not reflect the overall situation of Haskell developers. --- which Haskell implementations are you using (please indicate rough --- version info: "whatever", "latest source release", "latest binary --- release", "latest CVS", "latest stable version", ..)? GHC: 40 (own experimental branch, latest stable, latest rpm, 5.02.2,5.02.3,5.04 binary, latest binary, latest CVS (occasionally), latest, latest source release, latest from debian unstable) Hugs98: 33 (dec 2001, nov 2001, feb 2001, may 1999, latest binary, latest stable, latest, latest source release, latest CVS, latest from debian testing/stable, whatever) nhc98: 12 (1.14, latest binary, latest stable, latest CVS, latest source release) hbc: 1 (0.99995b, 1999 apr 02) --Comments The distribution itself is not unexpected. A small number of programmers use only a single implementation (GHC or Hugs). The majority seems to combine two or even all three of the currently maintained implementations, mostly for specific advantages of Hugs or nhc. Although GHC seems to be catching up with its latest releases, trying to be the one tool for all purposes, advantages mentioned include: quick prototyping and scripting use via runhugs (Hugs), profiling, tracing, debugging (nhc). Depending on the quality and completeness of improvements in these areas in forthcoming GHC versions, a few programmers indicate that they might reduce their use of other implementations. Another advantage mentioned in favour of multiple implementations is security from redundancy and variety: getting alternative "opinions" and diagnostics on obscure errors and avoiding inadvertent use of non-portable features. However, the differences in supported features are also mentioned as a disadvantage, making it difficult or impossible to take advantage of other implementations and their strengths. Use of latest stable source/binary releases dominates over the use of latest experimental/CVS versions. ------ to what extent do you use (which?) features outside Haskell 98? None: 8 (plus several who only use FFI, or what external libraries require) Multiparameter type classes: 20 Existential types: 15 FFI: 10 Functional dependencies: 9 rank-n polymorphism: 7 (sometimes, just n=2) Hierarchical module system: 4 HsLibs: 2 Hierarchical libraries: 2 Overlapping instances: 5 Class/instance-restrictions: 4 GHC state threads: 3 Implicit parameters: 3 Undecidable instances: 3 Pattern guards: 2 Unboxed types: 2 Exceptions: 2 Concurrency: 3 Dynamic types: 1 Monad comprehensions: 1 TREX: 1 -fglasgow-exts: 1 unsafePerformIO: 1 --Comments A substantial part of respondents would favour programming within the limitations of Haskell 98, if only for being able to use all of the available implementations and the complementary tools they offer. The main exceptions are multiparameter type classes, explicit existential and universal quantification, functional dependencies, and the new foreign function interface (the latter now being an official addendum to the standard). Another frequent comment concerns the need to use libraries beyond the standard (hugs/ghc-libs, hslibs, now the hierarchical libraries), and thus whatever advanced features those might depend on, emphasizing the urgency of convergence of Haskell implementations in this matter. Other features are used (or mentioned?) less frequently, although this might be a matter of unnoticed use of non-standard features (e.g., the low number of responses mentioning lifted class/instance-restrictions seems to be at odds with the high numbers mentioning multiparameter classes and functional dependencies). One answer suggested that removing advanced features after prototyping would lead to production code that is easier to understand and hence easier to maintain and debug later. ------- what editors, IDEs or source-manipulation tools are you using? -------------------------------------------------------------- editors Emacs 21 XEmacs 11 Vim/GVim 8 Vi 3 NEdit 4 BBEdit 1 -------------------------------------------------- tag-file generators None 39 (didn't know about it, will check, xemacs menu) HaskTags 3 fptags 1 custom 2 (etags) --------------------------------------------- documentation generators None 30 (will use, can't use [CVS ident conflicts, browser dependency]) Haddock 7 hdoc 1 IDoc 1 literate prg 3 (haskell.sty, lhs2TeX) LambdaTeX 1 a2ps 1 custom 5 ------------------------------------ pre-processors/program generators None 28 (try to avoid) cpp 12 (debugging, porting) DrIFT 6 strafunski 1 PolyP 1 GreenCard 2 c2hs 2 hsc2hs 1 happy 1 utrecht AG 1 (attribute grammar system) HaXml 1 hat-trans 1 m4 1 custom 3 ----------------------------------------------------- revision control None 4 CVS 30 (better alternatives sought..) manual 9 RCS 4 PRCS 2 Subversion 2 VCS 1 ------------------------------------------------ dependency generation custom 1 (to avoid too frequent recompilations by standard Haskell make tools) --Comments The editors in use are not nearly as varied as expected (which might be another indication of a bias in the sample of responses). The indication of the top ranks (emacs variants, followed by vi variants) is not unlikely, however. The single most frequent comment regarding tag-file generators is roughly "now that I know about this, I'll check it out". The single most frequent comment regarding documentation generators is roughly "don't use them yet, will do in future", with a clear tendency (of planned and existing use) towards Haddock (one response mentioned problems with CVS identifiers and browser dependencies currently preventing use of this tool though). There seems to be a variety of custom-made solutions as well. The single most frequent comment regarding preprocessors is "I try to avoid them", and almost two third of the respondents seem to manage to do so. Unfortunately, the single most frequently used preprocessor is also the least favoured: cpp. The main reasons given are conditional compilation for debugging and porting - perhaps it is time to standardize Haskell-specific variants of these features? cpp is followed in frequency by tools supporting generic programming, an ongoing focus of research, and tools supporting the use of Haskell's FFI. Again, there are several custom-made tools in use, one respondent mentions an inhouse Haskell preprocessor hpp. As far as revision control is concerned, CVS is clearly the most used variant, but it is not necessarily the most loved one. Several answers commented on an ongoing search for better alternatives. --------------- 2. To what extent are your editors/IDEs Haskell-aware? ------------------- what Haskell-specific functionality do they offer? none/haven't tried/don't use it 9 syntax highlighting 34 (sometimes confused; lacks support for language extensions; some features could be different; also used for printouts) pretty-printing 18 (or simple auto-indenting; problems with different layout styles?; often sluggish) tag-files 12 haskell mode 11 (could be significantly improved, sometimes wrong when it tries to be smart) syntax-aware movements 9 display (declared) function types 5 (should not be limited to declared types, nor to fixed set only) inserting inferred types 1 (custom solution) GHCi integration 3 GHCi/Hugs session in separate window 3 scan declarations and put them in menu 1 editor integration in Hugs :find/:edit 1 (find definition, edit next error) keyboard shortcuts/mappings 1 --Comments It is slightly surprising that a substantial number of Haskellers don't use Haskell-specific functionality in their editors, especially since almost all editors mentioned offer support for language-specific customization. One reason might be that editor customization is an art in itself (both the emacs and vim manuals are already quite daunting in size and tend to grow faster than most users learn new features, and this is "only" the editor), but it takes only a few hackers to do the customization for each editor, so there have to be other factors. Specific factors mentioned include "haven't looked yet", "don't know what else it can do", "I use this or that haskell-mode, which probably does a lot of the things you mention, but I haven't used those yet" and also "I tried this or that haskell-mode, but wasn't happy with it, so I don't use [it | most of it's features]". There are definite gaps between features available, features known, and features used or wanted. Apart from releasing private customizations (emacs users are ahead in this), more documentation (how to find out about Haskell-specific editing functionality if you don't have the editor or Haskell-mode installed yet?) and communication (what is it you'd like to be able to? what do you think is wrong with the current Haskell-modes?) seem to be called for. The widely used syntax highlighting (note though that not everyone uses even this feature) shows that Haskellers are willing to use customised features, if they are easily available and easy to use, even though there are some problems even with this feature (mostly because it is typically not based on proper parsing). Many features are rather more basic than most users would like. Pretty-printing (semi-automatic layout) and language-sensitive movement/selection are the most often mentioned features, with semi-automatic layout seeming especially problematic. Not all that many Haskellers seem to count the typical "bug-spotting" integration (try to compile, then jump to first error position) as important, only one response mentioned the editor integration in Hugs. --------------- what non-Haskell-specific editing functionality do you --------------- find most helpful when developing Haskell programs? none/don't know 3 matching of parentheses 28 macro recording and playback 12 (small, repetitive tasks that don't warrant a script; adding fun args, creating large aggregate data structures; reformatting code; add/remove {- -}; consistently rename families of functions, or change constructor representations) integration with external tools 10 (ghci, hugs, make&jump to error, shell, directory editor, spell checkers, email, text filters, RCS, CVS) search&replace with reg.exprs 7 autocomplete 4 tags/jump to definition 2 editor scripting 2 insert/cut/paste rectangle 2 grep 1 justification of comments and text 1 line/column numbering and finding 1 abbreviations 1 filetype dependent key bindings 1 diff mode 1 syntax highlighting of LaTeX in .lhs 1 --Comments The small number of "don't know" entries in this section is slightly misleading as a large number of Haskellers seem to use little more than matching of parentheses, and a few find even this less useful than in C or Java (thanks to layout, and less noisy syntax), or don't think their editor supports this feature (IIRC, all editors mentioned here do). The emphasis on using external text-processing tools from within the editor is probably typical for the unix bias in the survey responses, but beyond macro recording&playback and search&replace, only limited use seems to be made of more advanced editor-internal features (which are, after all, what distinguishes the "programmer's editors" from your basic notepad, and are often supported across platforms). Again, that might be a consequence of the unix tool chain, but not all editing functions are conveniently replaced by delegating them to external tools (sed notwithstanding;-). ---- what Haskell-specific editing functionality do you you miss most? don't miss it (because I never had it in a form I'd want to use) 6 display type of function at cursor/ query type of things 7 (also show comments and :info) integration with Haddock, Haskell98/Lib report and haskell.org info 2 (extended :info) finding types in modules that don't type-check completely 2 incremental syntax/type checking 3 integration with TypeView 1 (http://www-users.cs.york.ac.uk/~olaf/PUBLICATIONS/typeview.html) better auto-indenting 10 (without explicit braces/ semicolons; maintain layout against changes of identifier lengths, both interactively and during search&replace; configurable to personal style; re-align at "=") switch between braces/semicolon-style and layout-style for marked block 2 (to maintain layout during complex edits: switch to explicit braces style, edit, switch back to layout style) editor support for layout rule 1 (colouring hints for potential layout problems?) better syntax highlighting 1 find callers to function/occurrences of identifiers/show call graphs 3 (custom scripts; avoid costs of compilation?) class browser 1 module browser/function finder 2 rename identifier and all uses, handling syntax, scopes, and kinds correctly 4 (likely to mess up formatting, and automatic indentation may not be what you want; should work for all kinds of identifiers) proper (haskell-based, not lisp-based) syntax-sensitive movement/selection 2 scope-aware tags function 1 (find the def that will be used, not just any global one) change order of parameters at definition and all call sites 1 change type of constructor and all uses 1 (http://cs.oregonstate.edu/~erwig/papers/{hula.pdf,uc.pdf}) extend data type and all uses 1 moving definitions between local and global scopes 1 splitting/joining modules 1 extract function and replace repeated bodies by calls to new function 1 (also for type synonyms) support for refactoring (either do it, or prove it correct) 1 autocomplete 1 "locate bug" feature 1 (really!-) debugger integration, breakpoints, .. 1 integration with profiling tools 1 "Proof General"-style interface 1 (http://www.proofgeneral.org) toolbar/sidebar for Haskell 1 writing editor modules in haskell 1 KDevelop Haskell mode 1 (kdevelop-devel(a)kdevelop.org) don't always treat identifiers as single words for editing operations 2 jump to definition/documentation 1 function folding 1 --Comments Again, there's a small number of "happy as it is?" users. Interestingly, most of these comment that they've tried the existing features and haven't found them convincing in their current form. And indeed, many wishes are about better versions of current features. Item number one on the wish list is easy access to more information about the items currently edited. For completeness, it should be mentioned here that (some of) the emacs Haskell-modes already support (limited) versions of this, which not all respondents seem to be aware of. However, most answers pointed out limitations in the existing systems (should work for functions without declarations, and not be limited to fixed set of functions; should work incrementally and in only partially type-correct modules), or opportunities for improvements (offer to show :info and comments as well; integration with documentation tools and with standards documents). Next on the list comes more useable support for semi-automatic layout. Finding uses of identifiers (as opposed to finding definitions) would be a popular feature, and extends to call graphs and class/instance- and module-hierarchy browsers. Renaming of identifiers (of all kinds) and their uses, properly respecting Haskell syntax and scoping, and without inadvertently messing up layout, is beyond simple search&replace, and the first refactoring on the list of suggestions. It is followed by a list of other typical refactoring-style editing operations proper support for which would require syntax-aware tools. Integration with other Haskell-specific tools, profilers, tracers and debuggers specifically, would be more interesting now that such tools actually exist. One response pointed out that between general text editing and Haskell-specific functionality there is a range of language-independent operations that could be supported by integration with AST-based tools, referring to www.program-transformation.org. ---------------- what interface options does your editor/IDE offer for ---------------- integration of external tools (brief explanations or ---------------- pointers to detailed documentations would be great)? --Comments This question was a last-minute addition to the survey, and while it caused a lot of confusion, it didn't actually produce any useable answers (beyond the answers to previous questions). The idea was not so much that I expected everyone to work on extending his/her favourite editor for day-to-day editing tasks. Rather, I was hoping for some pointers to information about how tools like our envisioned refactorers could be intergrated into your favourite editors. Given the surprisingly small spread in editors used, the lack of answers here isn't much of a problem - just making sure that our tools can be integrated into emacs and vim should be a good enough start.

1 0

one C compiler
by Scott J. 06 Aug '02

06 Aug '02

Hi, I want to know if I have to use the same c compiler with which GHC was ported to windows or may I use other C compilers for poting C to GHC? Thx John Scott

1 0

ugliness with state parameter in ST stuff
by Hal Daume III 06 Aug '02

06 Aug '02

Sorry for the flood of emails this morning, but I've got something which has really got me scratching my head. Suppose I have a class: > class Foo a where > foo :: a -> IO Int and a datatype with a single function: > data Bar s = Bar (STArray s Int Int) > > getFirst :: Bar s -> ST s Int > getFirst (Bar arr) = readArray arr 0 Now, I want to make (Bar s) and instance of Foo. But I can't seem to do this. If I use: > instance Foo (Bar s) where > foo = stToIO . getFirst GHC complains: Cannot unify the type-signature variable `s' with the type `RealWorld' Expected type: Bar s -> IO Int Inferred type: Bar RealWorld -> IO Int In the expression: stToIO . getFirst In the definition of `foo': stToIO . getFirst and if I use: > instance Foo (Bar s) where > foo = return . runST . getFirst GHC complains: Inferred type is less polymorphic than expected Quantified type variable `s' escapes Expected type: ST s a -> c Inferred type: (forall s1. ST s1 a) -> a In the first argument of `(.)', namely `runST' In the second argument of `(.)', namely `runST . getFirst' Is there no way to do this? I can change the definition of Foo to: > class Foo2 a where > foo2 :: (forall s . a s) -> IO Int I can define: > instance Foo2 Bar where > foo2 = stToIO . getFirst Which I suppose works, but the problem is that in real life, "Foo" is "Binary" and I can't really change it. Suggestions? (Other than simply moving all my ST stuff over to the IO monad?) - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

3 3

difference between (evaluate . runST) and stToIO
by Hal Daume III 06 Aug '02

06 Aug '02

I can't seem to figure out what the difference is between using evaluate (runST action) and stToIO action when in the IO monad and running something in ST...they seem to behave identically...are they? If they are, why do they have different type signatures (one is ST RealWorld a -> IO a, while the other is (forall s. ST s a) -> IO a)? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 0

UTF-8 library
by Martin Norbäck 06 Aug '02

06 Aug '02

In a previous thread on this mailing list I proposed a way to use gettext. Since Haskell uses Unicode to represent characters, and gettext has support for converting strings into UTF-8, I made that the default mode of operation in my I18N module. I found a UTF8 library, which I modified to pass illegal UTF-8 sequences through unchanged. Since Haskell uses Unicode, and UTF-8 is one of the most common encodings for unicode, it would be good to have a UTF-8 library like this. You can find the files at http://www.dtek.chalmers.se/~d95mback/gettext/ where you also can find a printf-like implementation. I would very much like to hear some comments, also on the use of unsafePerformIO with locale-dependent functions (gettext is of course locale-dependent). Regards, Martin -- Martin Norbäck d95mback(a)dtek.chalmers.se Kapplandsgatan 40 +46 (0)708 26 33 60 S-414 78 GÖTEBORG http://www.dtek.chalmers.se/~d95mback/ SWEDEN OpenPGP ID: 3FA8580B

4 4

Fw: multiple C compilers
by Scott J. 06 Aug '02

06 Aug '02

Perhaps a silly question for the experts but I need an answer. Thx Scott ----- Original Message ----- From: Scott J. To: haskell-cafe(a)haskell.org Sent: Tuesday, August 06, 2002 1:56 AM Subject: multiple C compilers Hi, This is perhaps an idiot question , but I would like to know if one has to stick with one c compiler or if one can use different c compilers for Haskell2C ? Thx Scott

2 1

Fw: Jcreator
by Scott J. 06 Aug '02

06 Aug '02

Sorry for the inconvenience but I get not response on Haskell-Cafe. Thx Scott ----- Original Message ----- From: Scott J. To: haskell-cafe(a)haskell.org Sent: Tuesday, August 06, 2002 2:00 AM Subject: Jcreator Hi, can Jcreator be used also with GHC or only with Hugs as an IDE for Haskell? Thx Scott

1 0