- Glasgow-haskell-users

[ ghc-Feature Requests-1084122 ] RPM doesn't support --prefix
by SourceForge.net 08 May '05

08 May '05

Feature Requests item #1084122, was opened at 2004-12-13 10:54 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_… Category: None Group: None Status: Open Priority: 5 Submitted By: John Skaller (skaller) Assigned to: Nobody/Anonymous (nobody) Summary: RPM doesn't support --prefix Initial Comment: After installing ghc for linux using rpm with --prefix=/usr/local, the ghc scriipt incorrectly thinks the libraries etc are in /usr: #!/bin/sh GHCBIN="/usr/lib/ghc-6.2.2/ghc-6.2.2"; TOPDIROPT="-B/usr/lib/ghc-6.2.2"; # Mini-driver for GHC exec $GHCBIN $TOPDIROPT ${1+"$@"} After editing, at least the compiler actually starts up :) ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-09 08:57 Message: Logged In: YES user_id=139853 Not really sure what the right solution is - one hack that comes to mind is adding a %post install script in the spec file that would replace the default prefix with the specified one. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-04-12 22:06 Message: Logged In: NO Still a problem with 6.2.4 - Additionally, you now need to edit the package.conf file. Karl M. Syring syring(a)email.com ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-14 01:26 Message: Logged In: YES user_id=48280 Re-opened. Any RPM gurus out there who could knock this one on the head? Note it's not just the ghc script, there's a couple of other scripts that need munging (ghci, ghc-pkg, hsc2hs maybe). ---------------------------------------------------------------------- Comment By: John Skaller (skaller) Date: 2004-12-13 23:54 Message: Logged In: YES user_id=5394 I can see it isn't supported :) However after the change to those two lines, the compiler works, links libraries, and the resultant binary executes correctly (as far as I can tell never having written any Haskell before .. :) So why not support it? I had no choice .. my root partition, containing /usr is 97% full.. :) ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2004-12-13 21:54 Message: Logged In: YES user_id=48280 You're trying to install the binary RPM using a different prefix? That's not supported, I'm afraid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1084122&group_…

1 0

problem with xlib binding
by Frederik Eaton 08 May '05

08 May '05

Hi, Hmm, have the new xlib bindings been tested? For instance, when I run the following program: ---------------------------------------------------------------- module Main where import Graphics.X11.Xlib import Graphics.X11.Xlib.Display main :: IO () main = do display <- openDisplay "" root <- rootWindow display $ defaultScreen display getGeometry display root closeDisplay display return () ---------------------------------------------------------------- It prints out: xtest: user error (Error bad status 1 raised in function getGeometry) >From the code it looks like the haskell getGeometry is calling XGetGeometry - which has type Status XGetGeometry(...) - and interpreting the 1 return value as an error (via the internal wrapper 'throwUnlessSuccess' which takes 0 for success). But the Xlib Programming Manual says "Some errors, such as failure to open a font, are indicated by return values of type Status on the appropriate routine ... The returned values are *zero* on failure and *nonzero* on success." (emphasis added) So unless I'm really misinterpreting things, the binding to each and every one of the 13 functions that uses 'throwUnlessSuccess' is wrong. Well, before I realized this I'd gone ahead and written a reasonably significant program against the binding assuming that at least the basics would work, but it seems there is some distance to go before the library is usable. One would think that with a "Stability: provisional" library every function has been run successfully at least once, but I can't imagine that this is the case here. Is there even a working Haskell equivalent of 'basicwin' from the Xlib Programming Manual to test things out? This would also be a helpful example for users. Regards, Frederik -- http://ofb.net/~frederik/

1 1

foldr f (head xs) xs is not the same as foldr1 f xs
by David Sabel 08 May '05

08 May '05

Hi! A small example for the claim mentioned in the subject: Prelude> let x = 1:undefined in foldr (curry fst) (head x) x 1 Prelude> let x = 1:undefined in foldr1 (curry fst) x *** Exception: Prelude.undefined Perhaps it would be better to change the implementation of foldr1? Cheers, David

3 3

[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
by SourceForge.net 08 May '05

08 May '05

Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Closed Priority: 3 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-08 17:32 Message: Logged In: YES user_id=139853 Just naively replacing DsForeign.lhs and Adjustor.c with the current versions from cvs trunk seems to work well so far though. :-) [ At least I got wxhaskell samples running with them on ghc-6-4-branch. :] ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-01-21 05:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 19:34 Message: Logged In: YES user_id=728695 Hi! Just to add it's important issue for me since it affects the general gui-availability for Haskell language on amd64 platform since gtk2hs bindings also depend on it. Pls. raise this priority a little bit - amd64 is really a very 'natural' platform for Haskell :-) Sincerely, Gour ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-07 06:48 Message: Logged In: YES user_id=566359 Yes, this is just a "missing feature". A small piece of platform specific code (<50 lines) is required to get foreign import "wrapper" declarations to work, and wxhaskell uses them a lot. A volunteer who wants to fix this would need enough knowledge about assembly language in general to really understand a calling convention (literature on amd64's particular calling convention is available somewhere). Most of the amd64-specific details can be picked up on the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_…

1 0

[ ghc-Feature Requests-1097471 ] amd64: adjustor creation not supported
by SourceForge.net 06 May '05

06 May '05

Feature Requests item #1097471, was opened at 2005-01-07 05:55 Message generated for change (Comment added) made by juhp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_… Category: None Group: None Status: Closed Priority: 3 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: amd64: adjustor creation not supported Initial Comment: Hello, when trying to use wxhaskell on ghc-6.2.2 on an amd64 (unregistered gentoo build) the following happend: $ ./a.out a.out: internal error: adjustor creation not supported on this platform Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ I'm not sure if this is a bug because amd64 is not officially supported. ---------------------------------------------------------------------- Comment By: Jens-Ulrik Petersen (juhp) Date: 2005-05-07 11:07 Message: Logged In: YES user_id=139853 I tried ghc-6-4-branch to test this, but it seems the changes have not been merged there yet. ---------------------------------------------------------------------- Comment By: Simon Marlow (simonmar) Date: 2005-03-11 18:19 Message: Logged In: YES user_id=48280 Sorry :-( I implemented this yesterday. It was too late for 6.4, though (it'll be in 6.4.1). If you're interested in the code, take a look at Adjustor.c in CVS. I had to do some delicate hacking to work around the calling convention on x86_64, but fortunately it isn't as tricky as the powerpc version. Thanks for looking at this, and sorry I stepped on your toes! ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-03-11 17:31 Message: Logged In: YES user_id=349837 OK, I'm trying this. First I tried to do it the very same way as in x86: pushing hptr and obscure_ret_addr to stack. Of course, this doesn't work out because x86_64 does use REGISTER for the first 6 (in) arguments/paramenters. Next I tried to get hptr as second/#2 and obscure_ret_addr as first/#1 REGISTER parameter, shifting all REGISTER by 2 (and pushing arguments #6 and #5) to stack. Of course this does not work because obscure_ret is the (faked) return address and should be on the stack. My main problem is that I don't understand what is the the second argument (BaseReg) of StgRun(StgFunPtr f, StgRegTable *basereg) in StgCRun.c . How is this used in x86??? For me x86 stack for _ccall in Adjustor.c looks like: ??? 2nd arg to called haskell land function ??? 1st arg to called haskell land function ??? obsolete_ret_addr hptr obscure_ret_addr >From this it is difficult for me to see any BaseReg joining the game. In other architectures (i.e. sparc) the in REGISTER are a shifted by 2 as well. But in this architecture you don't need the obscure_ret_addr stuff. The bottom line is the following: I understand ghc adjustor, x86, and x86_64 calling convention. BUT the x86 part concering the BaseReg is pretty undocumented. Perhaps someone could give me a hand being more verbose in what is needed in the x86_64 adjustor... Cheers, aanno ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-21 07:29 Message: Logged In: YES user_id=566359 The StgFunPtr that is passed to createAdjustor is a pointer to a normal C function (using the standard C calling convention) that takes as it's first argument the StgStablePtr hptr, a second "dummy" argument of the same size that is ignored (this is to help the implementation for the x86 ABI), and then all the arguments that were passed from the constructor. Note that if you need to do something to the stack after the function returns (rather than just tail-calling the function), you should arrange for the function to return to some static piece of code (see obscure_ccall_ret_code for x86) rather than to the adjustor itself. This is because the function might deallocate the adjustor. ---------------------------------------------------------------------- Comment By: Thomas Pasch (aanno) Date: 2005-01-21 05:20 Message: Logged In: YES user_id=349837 OK, I will have a try on this. I sort of understand x86 and x86_64 abi at the moment. There is only one question left at the moment: After I jump to StgFunPtr (a StgFun?) what will happen? Is this (a) a normal C land function that will require its argument (StgStablePtr hptr) as a 1st argument of the "universal" calling convention OR (b) some other kind of magic (from what source code?) that will pop its argument from the stack? Any answer would be appreciated. aanno ---------------------------------------------------------------------- Comment By: Gour (ggd) Date: 2005-01-08 19:34 Message: Logged In: YES user_id=728695 Hi! Just to add it's important issue for me since it affects the general gui-availability for Haskell language on amd64 platform since gtk2hs bindings also depend on it. Pls. raise this priority a little bit - amd64 is really a very 'natural' platform for Haskell :-) Sincerely, Gour ---------------------------------------------------------------------- Comment By: Wolfgang Thaller (wthaller) Date: 2005-01-07 06:48 Message: Logged In: YES user_id=566359 Yes, this is just a "missing feature". A small piece of platform specific code (<50 lines) is required to get foreign import "wrapper" declarations to work, and wxhaskell uses them a lot. A volunteer who wants to fix this would need enough knowledge about assembly language in general to really understand a calling convention (literature on amd64's particular calling convention is available somewhere). Most of the amd64-specific details can be picked up on the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1097471&group_…

1 0

Error building ghc 6.4 under os x
by Jeffrey Vaughan 05 May '05

05 May '05

Hi All, I'm trying to build ghc 6.4 on mac os x (10.3) using ghc 6.2. The build dies with "/tmp/ghc18478.hc:3:17: Stg.h: No such file or directory". An abridged session transcript is below. Any ideas about what's going on? Thanks! --Jeff root@Narcissus ghc-6.4 # autoreconf root@Narcissus ghc-6.4 # ./configure [seems to work file] root@Narcissus ghc-6.4 # make ------------------------------------------------------------------------ ===fptools== Recursively making `boot' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/mkdependC ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/mkdirhier ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/runstdtest ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot -r; in /usr/local/ghc-6.4/glafp-utils/lndir ------------------------------------------------------------------------ ../../glafp-utils/mkdependC/mkdependC -f .depend -- -O -- lndir.c ------------------------------------------------------------------------ ===fptools== Finished making `boot' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils ------------------------------------------------------------------------ ------------------------------------------------------------------------ ===fptools== Recursively making `all' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/mkdependC ------------------------------------------------------------------------ make[2]: Nothing to be done for `all'. ------------------------------------------------------------------------ ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/mkdirhier ------------------------------------------------------------------------ make[2]: Nothing to be done for `all'. ------------------------------------------------------------------------ ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/runstdtest ------------------------------------------------------------------------ make[2]: Nothing to be done for `all'. ------------------------------------------------------------------------ ==fptools== make all -r; in /usr/local/ghc-6.4/glafp-utils/lndir ------------------------------------------------------------------------ make[2]: Nothing to be done for `all'. ------------------------------------------------------------------------ ===fptools== Finished making `all' in mkdependC mkdirhier runstdtest lndir ... PWD = /usr/local/ghc-6.4/glafp-utils ------------------------------------------------------------------------ ------------------------------------------------------------------------ ===fptools== Recursively making `boot' in includes lib utils driver docs compiler rts ... PWD = /usr/local/ghc-6.4/ghc ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot -r; in /usr/local/ghc-6.4/ghc/includes ------------------------------------------------------------------------ ../../glafp-utils/mkdependC/mkdependC -f .depend -- -O -- mkDerivedConstants.c ------------------------------------------------------------------------ ==fptools== make boot -r; in /usr/local/ghc-6.4/ghc/lib ------------------------------------------------------------------------ ------------------------------------------------------------------------ ===fptools== Recursively making `boot' in compat ... PWD = /usr/local/ghc-6.4/ghc/lib ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==fptools== make boot - --no-print-directory -r; in /usr/local/ghc-6.4/ghc/lib/compat ------------------------------------------------------------------------ ../../../glafp-utils/mkdependC/mkdependC -f .depend -I../../includes -- -O -- cbits/directory.c cbits/rawSystem.c /sw/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp Compat/Directory.hs Compat/RawSystem.hs Distribution/Compat/ReadP.hs Distribution/Extension.hs Distribution/GetOpt.hs Distribution/InstalledPackageInfo.hs Distribution/License.hs Distribution/Package.hs Distribution/ParseUtils.hs Distribution/Setup.hs Distribution/Version.hs System/Directory/Internals.hs <<ghc: 7384080 bytes, 3 GCs, 41848/41848 avg/max bytes residency (1 samples), 16M in use, 0.01 INIT (0.02 elapsed), 0.05 MUT (1.85 elapsed), 0.01 GC (1.26 elapsed) :ghc>> make all rm -f Compat/Directory.o; if [ ! -d Compat/Directory_split ]; then mkdir Compat/Directory_split; else /usr/bin/find Compat/Directory_split -name '*.o' -print | xargs rm -f __rm_food; fi; /sw/bin/ghc -H16m -O -I. -Rghc-timing -I../../../libraries -fglasgow-exts -no-recomp -split-objs -c Compat/Directory.hs -o Compat/Directory.o -ohi Compat/Directory.hi /tmp/ghc14786.hc:3:17: Stg.h: No such file or directory /tmp/ghc14786.hc:4:20: HsBase.h: No such file or directory /tmp/ghc14786.hc:6: error: parse error before "START_MOD_INIT" /tmp/ghc14786.hc:7: error: parse error before "EF_" /tmp/ghc14786.hc:7: warning: type defaults to `int' in declaration of `EF_' ... lots more ... /tmp/ghc14786.hc:1268: error: parse error before '}' token <<ghc: 73185768 bytes, 15 GCs, 2345088/4627896 avg/max bytes residency (3 samples), 18M in use, 0.01 INIT (0.06 elapsed), 0.71 MUT (1.87 elapsed), 0.31 GC (0.38 elapsed) :ghc>> make[4]: *** [Compat/Directory.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make: *** [build] Error 1

2 5

multiple versions of ghc
by Malcolm Wallace 05 May '05

05 May '05

Is it true that on unix, tools like ghc-pkg-6.2.2 and ghc-pkg-6.4 may co-exist, but on Windows the version number is not present, so a single executable is simply called ghc-pkg.exe? If so, how do Windows users deal with having more than one version of ghc installed simultaneously? Is this just a bug/oversight that can be fixed? Regards, Malcolm

2 1

RE: installing ghc without already having ghc
by Simon Marlow 05 May '05

05 May '05

On 03 May 2005 18:55, Jessica Brennan [staff] wrote: > I was able to fix my previous errors by adding -I/usr/local/bin. > However I am getting more errors later in the build. > > In stage 2 of the cross compiling build I am getting errors at this > phase: $ cd H/ghc/lib > $ make clean > $ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' > > ------------------------------------------------------------------------ > ===fptools== Recursively making `all' in compat ... > PWD = /devel/build/NetBSD/ghc/ghc-6.4-host/ghc/lib > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > ==fptools== gmake all -rk; > in /devel/build/NetBSD/ghc/ghc-6.4-host/ghc/lib/compat > ------------------------------------------------------------------------ > ../../../ghc/compiler/stage1/ghc-inplace -H16m -O -H32m -I. > -Rghc-timing > -I../../../libraries -fglasgow-exts -no-recomp -O -fvia-C > -keep-hc-files > -c System/Directory/Internals.hs -o System/Directory/Internals.o -ohi > System/Directory/Internals.hi > > System/Directory/Internals.hs:1:0: > Module `System.Directory.Internals' is a member of package > base-1.0. To compile this module, please use -ignore-package > base-1.0. <<ghc: 13436620 bytes, 3 GCs, 47324/47324 avg/max bytes > residency (1 samples), 31M in use, 0.00 INIT (0.01 elapsed), 0.22 MUT > (2.29 elapsed), > 0.04 GC (0.29 elapsed) :ghc>> > gmake[1]: *** [System/Directory/Internals.o] Error 1 Someone else has reported the same problem, but I still don't know what causes it. Could you try the following and send me the output: $ cd ghc/lib/compat $ make show VALUE=ghc_ge_603 $ make show VALUE=EXCLUDED_SRCS $ make show VALUE=HS_SRCS and this *might* fix it: $ rm .depend $ make boot UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' $ make UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files' Cheers, Simon

2 2

RE: deprecate a constructor?
by Simon Peyton-Jones 05 May '05

05 May '05

OK, I've fixed this one, in the HEAD at least. You can now deprecate data constructors as well as type constructors. Not in the 6.4 branch though, because doing so could conceivably make some programs fail. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Simon Peyton-Jones | Sent: 15 April 2005 14:58 | To: Johannes Waldmann; glasgow-haskell-users(a)haskell.org | Subject: RE: deprecate a constructor? | | Apparently not at the moment but it should be. | | As in a 'hiding' list, deprecating "T" would deprecate the *type* T and | the *data constructor* T. There'd be no way to deprecate one without | the other, except by giving them different names. (That's a bit of a | shortcoming in hiding lists already, so matters are no worse than | before.) | | I'll look into this sometime I'm on an aeroplane... | | Simon | | | -----Original Message----- | | From: glasgow-haskell-users-bounces(a)haskell.org | [mailto:glasgow-haskell-users- | | bounces(a)haskell.org] On Behalf Of Johannes Waldmann | | Sent: 14 April 2005 17:27 | | To: glasgow-haskell-users(a)haskell.org | | Subject: deprecate a constructor? | | | | is it possible to {-# DEPRECATE #-} a single constructor | | (of a data declaration that is, as a whole, not deprecated)? | | -- | | -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- | | ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- | | | | _______________________________________________ | | Glasgow-haskell-users mailing list | | Glasgow-haskell-users(a)haskell.org | | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Unicode source files
by Simon Marlow 05 May '05

05 May '05

On 04 May 2005 15:57, Bulat Ziganshin wrote: > it is true what to support unicode source files only StringBuffer > implementation must be changed? It depends whether you want to support several different encodings, or just UTF-8. If we only want to support UTF-8, then we can keep the StringBuffer in UTF-8 and also FastStrings. (or you could re-encode the other encodings into UTF-8). > if so, then task can be simplified by > converting any files read by hGetStringBuffer to UTF-32 (PackedString) > representation and putting in memory array in this form. After this, > we must change indexing of ByteArray to indexing of Array Int Char, > and somewhat replace call to mkFastSubStringBA#. This is the other alternative. It uses rather more memory, but that might not be an issue. The other thing that needs to be changed is the lexer, to be able to recognise classes of Unicode characters (i.e. upper/lower case for identifiers, symbol characters. etc.). The code recently added to the libraries can be used for this, I believe. The question is what Alex should see for a unicode character: Alex currently assumes that characters are in the range 0-255 (you need a fixed range in order to generate the lexer tables). One possibility is to map all Unicode upper-case characters to a single character code for Alex, and similarly for the other classes of character. > btw, why in FastString module unicode strings are saved as [Int], not > as String itself? Probably for reasons that are no longer relevant. When we changed Char from 8 to 32 bits, we still had to compile GHC with older versions of itself that only supported 8-bit Chars. Cheers, Simon

1 0