Re: ghci: unknown symbol `__ashldi3
On 5 Oct 2001, Marcin 'Qrczak' Kowalczyk wrote: Fri, 5 Oct 2001 17:31:18 +0200, Ch. A. Herrmann [EMAIL PROTECTED] pisze: Loading package std ... linking ... /public/packages/programming/ghc-5.02/lib/ghc-5.02/HSstd_cbits.o: unknown symbol `__ashldi3' I guess you can add the symbol to ghc/rts/Linker.c and recompile ghc with the runtime using the new Linker.c (i.e. recompile twice). I tried this a few weeks ago but it didn't work. It caused a bunch of other error messages. I've included them in the end of this mail. I'm not sure why I got them, maybe I did something wrong. Cheers, /Josef ../../ghc/compiler/ghc-inplace -optc-O -optc-O2 -optc-fomit-frame-pointer -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-Wcast-align -optc-DCOMPILING_RTS -ldl -I../includes -I. -Iparallel -O2 -DCOMPILING_RTS -static-c Linker.c -o Linker.o In file included from ../includes/Stg.h:203, from ../includes/Rts.h:16, from Linker.c:11: ../includes/ClosureMacros.h: In function `get_entry': ../includes/ClosureMacros.h:66: warning: cast increases required alignment of target type Linker.c: At top level: Linker.c:369: `__ashldi3' undeclared here (not in a function) Linker.c:369: initializer element is not constant Linker.c:369: (near initialization for `rtsSyms[175].addr') Linker.c: In function `findElfSection': Linker.c:1506: warning: cast increases required alignment of target type Linker.c:1507: warning: cast increases required alignment of target type Linker.c: In function `ocVerifyImage_ELF': Linker.c:1530: warning: cast increases required alignment of target type Linker.c:1579: warning: cast increases required alignment of target type Linker.c:1633: warning: cast increases required alignment of target type Linker.c: In function `ocGetNames_ELF': Linker.c:1690: warning: cast increases required alignment of target type Linker.c:1692: warning: cast increases required alignment of target type Linker.c:1738: warning: cast increases required alignment of target type Linker.c: In function `do_Elf32_Rel_relocations': Linker.c:1844: warning: cast increases required alignment of target type Linker.c:1848: warning: cast increases required alignment of target type Linker.c:1849: warning: cast increases required alignment of target type Linker.c:1858: warning: unused variable `A' Linker.c: In function `do_Elf32_Rela_relocations': Linker.c:1916: warning: cast increases required alignment of target type Linker.c:1920: warning: cast increases required alignment of target type Linker.c:1921: warning: cast increases required alignment of target type Linker.c: In function `ocResolve_ELF': Linker.c:2028: warning: cast increases required alignment of target type Linker.c:2029: warning: cast increases required alignment of target type Linker.c:2032: warning: cast increases required alignment of target type make[2]: *** [Linker.o] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/users/cs/josefs/packages/fpbuild/ghc' make: *** [all] Error 1 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: GHC 5.02 Win32
Yes, non-interactive uses of the Win32 library appear to be in a non-working state (at least with my copy of ghc-5.02, don't know if there's been any stealth updates to the installer binary.) As a stop-gap measure, replace ghc-5.02's libHSwin32.a (after having saved it away) with the one contained in http://www.galconn.com/~sof/HSwin32.zip If your libHSwin32.a is built by and against 5.02, I'll just include it in my InstallShield tree and update. Unfortunately owing to limited disc space, I haven't been keeping as many trees around as I would have liked. However, I think I have a solution, so I should have a clean-built version soon. (The cause of it all is that libHSwin32.a lacks a pair of _stub.c files which contains the code that takes care of the window/dialogue callbacks into Haskell). Yes, I'm not at all clear on how that happened. Was that just before a fix you made to do with that? I notice that when I build libHSwin32.a now, I get an error because two non-existent directories get added to the link line, corresponding to those two _stub.c files. But the library builds properly anyway. Or at least, the given example works. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghci: unknown symbol `__ashldi3
Tue, 9 Oct 2001 10:10:40 +0200 (MET DST), Josef Svenningsson [EMAIL PROTECTED] pisze: Linker.c: At top level: Linker.c:369: `__ashldi3' undeclared here (not in a function) Bring it with Sym, not SymX. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Bug in GHC 5.02
I am writing to report a bug I have found in GHC
version 5.02. The problemis that I tried to compile a .hs file which
camewith Green Card's library and the following message
appeared:
"panic! (the 'impossible' happened, GHC version
5.02): Native code generator can't
handle foreign call {-_ccall-}__casm ``do {void *
arg1;
arg1 = (void
*)%0;
do {free(arg1);
} while(0);} while(0);'' arg1Please report it as a compiler bug to [EMAIL PROTECTED],or
http://sourceforge.net/projects/ghc/."
Othermessageslikethe one above
appeared when I tried to compile other files which used foreign
procedures.
Monique Monteiro
Re: Bug in GHC 5.02
To make this panic go away, try adding the option
"-fvia-C" to your GHC
command line.
(GHC could give a better error msg here, and
indicate that you have to
use -fvia-C with code that (still) uses
_casm_.)
hth
--sigbjorn
- Original Message -
From:
Monique Louise
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] ; [EMAIL PROTECTED]
Sent: Tuesday, October 09, 2001
12:41
Subject: Bug in GHC 5.02
I am writing to report a bug I have found in GHC
version 5.02. The problemis that I tried to compile a .hs file
which camewith Green Card's library and the following message
appeared:
"panic! (the 'impossible' happened, GHC version
5.02): Native code generator
can't handle foreign call {-_ccall-}__casm ``do {void *
arg1;
arg1 = (void
*)%0;
do {free(arg1);
} while(0);} while(0);'' arg1Please report it as a compiler bug to
[EMAIL PROTECTED],or
http://sourceforge.net/projects/ghc/."
Othermessageslikethe one above
appeared when I tried to compile other files which used foreign
procedures.
Monique Monteiro
RE: ghc-pkg
Hi! I would like to add a request to Thomas list of lacking features of ghc --make: When caching information between the compilation of different modules, use weak pointers. With large projects, ghc runs out of heapspace because of too much caching. It's always fine to restart the build process by doing ghc --make again but the whole thing is really annoying. I agree that caching is important and very nice, but it shouldn't make the building process to abort. /Josef On Mon, 8 Oct 2001, Simon Marlow wrote: Additionally, ghc --make lacks (AFAIK) several useful features found in other make tools (although not all in the same tool...): 1. The ability to distingush directories containing source code to be compiled from directories containing previously compiled code (hmake has the flags -P and -i, hbcmake has -i and -I). (I guess you could use -package-conf as a cumbersome substitute, though.) 2. The ability to specify compiler flags for individual modules without putting them in the source code. (Some flags are 'static' and can not be put in the source code.) 3. The ability to compile several modules in parallel, on a multi-processor machine, or a network of workstations. 4. The ability to automatically invoke program generators (e.g. happy)... 5. A graphical user interface. All valid arguments, of course. But in --make's favour, it *is* much faster than individual compiles. In a little test I did today, ghc --make beats hmake/nhc98 on a reasonably sized program (nofib/real/anna). I timed both with -H32m and no optimisation, ghc --make compiled it in 48 seconds compared to 51 seconds for hmake/nhc98. On small individual modules, nhc98 wins hands down though. Ok, so speed isn't everything, and I hear the arguments you enumerated above. Most of these can be achieved through extra compiler support, and the last one (a make GUI) should actually be easier with GHC once we get around to specifying the compiler's programmatic API more precisely. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HOpengl on Ghc 5.02
Nicolas [EMAIL PROTECTED] writes: Hi there, Sorry for this stupid question: Is there a distrib of a HOpenGl package working with ghc 5.02. I tried the CVS but don't manage to make it work (ghc 5.03 panic). Can someone help me? I got HOpenGL to work without trouble. On September 29, I checked out the ghc-5-02 branch from CVS, configured it with --enable-hopengl, and built and installed it. (I actually built a Debian package, using the Debian packager's build scripts.) I doubt if it matters, but I'm using HOpenGL with gtk+hs and gtkglarea instead of Glut. Carl Witty ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc 5.02 and Solaris ld
$ grep 'ld.*-x' `find . -name Makefile` ./ghc-5.02/ghc/lib/std/Makefile:ld -r -x -o $@ $(GHCI_LIBOBJS) ./ghc-5.02/ghc/lib/std/Makefile:ld -r -x -o HSstd1.o $(filter Prel%, $(GHCI_LIBOBJS)) ./ghc-5.02/ghc/lib/std/Makefile:ld -r -x -o HSstd2.o $(filter-out Prel%, $(GHCI_LIBOBJS)) ./ghc-5.02/hslibs/win32/Makefile: ld -r -x -o HSwin321.o $(filter Win32M% Win32N% Win32R% Win32W%, \ ./ghc-5.02/hslibs/win32/Makefile: ld -r -x -o HSwin322.o $(filter-out Win32M% Win32N% Win32R% Win32W%, \ It looks like ghc makefiles assume that I am using GNU ld. The -x option does not exist in Solaris version of ld. Is this just a bug or ghc was not meant to be linked with other versions of ld? Just wondering, I could always use GNU ld instead (its just not the first thing on my PATH) According to the SunOS ld manual '-z redlocsym' seems to do what -x does. -z redlocsym Eliminates all local symbols except for the SECT symbols from the symbol table SHT_SYMTAB. All relocations that refer to local symbols will be updated to refer to the corresponding SECT sym- bol. So, I'll try to edit the makefiles accordingly and see what happens. --akop ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: IO concurrency
I forgot to say: that's ghc-5.00.1, linux. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode support
Just to clear up any misunderstanding: - Original Message - From: Ashley Yakeley [EMAIL PROTECTED] To: Haskell List [EMAIL PROTECTED] Sent: Monday, October 01, 2001 12:36 AM Subject: Re: Unicode support At 2001-09-30 07:29, Marcin 'Qrczak' Kowalczyk wrote: Some time ago the Unicode Consortium slowly began switching to the point of view that abstract characters are denoted by numbers in the range U+..10. It's worth mentioning that these are 'codepoints', not 'characters'. Yes, but characters are allocated to code points (or rather code positions). Sometimes a character will be made up of two codepoints, for instance an 'a' with a dot above is a single character that can be made from the codepoints LATIN SMALL LETTER A and COMBINING DOT ABOVE. Well, those ARE characters, which together form a GRAPHEME (which is what Joe User would consider to be a character). Those two happen to 'combine' in NFC to LATIN SMALL LETTER A WITH DOT ABOVE. But that is just that example. LATIN SMALL LETTER R and COMBINING SHORT STROKE OVERLAY (yes, this is used in some places, but will never get a precomposed character) are left as is also for NFC. Both of these examples, for either normal form, MAY each be handled by one (ligature, if you like) glyph or by two (overlaid) glyphs by a font. Further, some code points are permanently reserved for UTF-16 surrogates, some are permanently reserved as non-characters(!), some are for private use (which can be used for things not yet formally encoded, or things that never will be encoded) and quite a lot are reserved for future standardisation. The 8, 16, or 32-bit units in the encoding forms are called 'code units'. E.g. Java's 'char' type is for UTF-16 code units, not characters! Though a single UTF-16 code unit can represent a character in the BMP (if that code position has a character allocated to it). In many cases, but definitely not all, a single character, in its string context, is a grapheme too. In summary: code position (=code point): a value between and 10. code unit: a fixed bit-width value used in one of the encoding forms (often called char in programming languages). character: hard to give a proper definition (the 10646 one does not say anything), but in brief roughly a thing deemed worthy of being added to the repertiore of 10646. grapheme: a sequence of one or more characters that naïve users think of as a character (may be language dependent). glyph: a piece of graphic that may image part of, a whole, or several characters in context. It is highly font dependent how the exact mapping from characters to positioned glyphs is done. (The partioning into subglyphs, if done, need not be tied to Unicode decomposition.) For most scripts, including Latin, this mapping is rather complex (and is yet to be implemented in full). Perhaps this makes the UTF-16 'surrogate' problem a bit less serious, since there never was a one-to-one correspondence between any kind of n-bit unit and displayed characters. With that I agree. Kind regards /kent k -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Unicode support
At 2001-10-09 02:58, Kent Karlsson wrote: In summary: code position (=code point): a value between and 10. Would this be a reasonable basis for Haskell's 'Char' type? At some point perhaps there should be a 'Unicode' standard library for Haskell. For instance: encodeUTF8 :: String - [Word8]; decodeUTF8 :: [Word8] - Maybe String; encodeUTF16 :: String - [Word16]; decodeUTF16 :: [Word16] - Maybe String; data GeneralCategory = Letter_Uppercase | Letter_Lowercase | ... getGeneralCategory :: Char - Maybe GeneralCategory; ...sorting searching... ...canonicalisation... etc. Lots of work for someone. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Unicode support
- Original Message - From: Ashley Yakeley [EMAIL PROTECTED] To: Kent Karlsson [EMAIL PROTECTED]; Haskell List [EMAIL PROTECTED]; Libraries for Haskell List [EMAIL PROTECTED] Sent: Tuesday, October 09, 2001 12:27 PM Subject: Re: Unicode support At 2001-10-09 02:58, Kent Karlsson wrote: In summary: code position (=code point): a value between and 10. Would this be a reasonable basis for Haskell's 'Char' type? Yes. It's essentially UTF-32, but without the fixation to 32-bit (21 bits suffice). UTF-32 (a.k.a. UCS-4 in 10646, yet to be limited to 10 instead of 31(!) bits) is the datatype used in some implementations of C for wchar_t. As I said in another e-mail, if one does not have high efficiency concerns, UTF-32 is a rather straighforward way of representing characters. At some point perhaps there should be a 'Unicode' standard library for Haskell. For instance: encodeUTF8 :: String - [Word8]; decodeUTF8 :: [Word8] - Maybe String; encodeUTF16 :: String - [Word16]; decodeUTF16 :: [Word16] - Maybe String; data GeneralCategory = Letter_Uppercase | Letter_Lowercase | ... getGeneralCategory :: Char - Maybe GeneralCategory; There is not really any Maybe just there. Yet unallocated code positions have general category Cn (so do non-characters): Cs Other, Surrogate Co Other, Private Use Cn Other, Not Assigned (yet) ...sorting searching... ...canonicalisation... etc. Lots of work for someone. Yes. And it is lots of work (which is why I'm not volonteering to make a qick fix: there is no quick fix). Kind regards /kent k ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
exercise 4.19
howMany :: Int - Int - Int - Int howMany n1 n2 n3 | (n1 a) (n2 a) (n3 a) = 3 | (n1 a) (n2 a) = 2 | (n1 a) (n3 a) = 2 | otherwise = 1 where a = (n1 + n2 + n3)/3 i get an error message ERROR C:\My Documents\Haskell programming\question4.19.txt:4 - Instance of Fract ional Int required for definition of howMany how could i resolved this ? _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Unicode support
At 2001-10-09 03:37, Kent Karlsson wrote: code position (=code point): a value between and 10. Would this be a reasonable basis for Haskell's 'Char' type? Yes. It's essentially UTF-32, but without the fixation to 32-bit (21 bits suffice). UTF-32 (a.k.a. UCS-4 in 10646, yet to be limited to 10 instead of 31(!) bits) is the datatype used in some implementations of C for wchar_t. As I said in another e-mail, if one does not have high efficiency concerns, UTF-32 is a rather straighforward way of representing characters. Would it be worthwhile restricting Char to the 0-10 range, just as a Word8 is restricted to 0-FF even though in GHC at least it's stored 32-bit? ... data GeneralCategory = Letter_Uppercase | Letter_Lowercase | ... getGeneralCategory :: Char - Maybe GeneralCategory; There is not really any Maybe just there. Yet unallocated code positions have general category Cn (so do non-characters): Cs Other, Surrogate Co Other, Private Use Cn Other, Not Assigned (yet) OK. It occured to me to put 'unassigned' as Nothing, since it might change -- so in a sense getGeneralCategory doesn't know what the GC is. I assume once a codepoint has a non-Cn GC, it cannot be changed. But confusingly, some of the GCs are 'normative', whereas others are merely 'informative' -- perhaps these last are subject to revision. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Unicode support
On Tue, 9 Oct 2001, Ashley Yakeley wrote: Would it be worthwhile restricting Char to the 0-10 range, just as a Word8 is restricted to 0-FF even though in GHC at least it's stored 32-bit? It is thus restricted in GHC. I think it's a good compromise between 32-bit-Unicode and 16-bit-Unicode camps :-) -- Marcin 'Qrczak' Kowalczyk ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: exercise 4.19
riz er [EMAIL PROTECTED] writes: howMany :: Int - Int - Int - Int howMany n1 n2 n3 | (n1 a) (n2 a) (n3 a) = 3 | (n1 a) (n2 a) = 2 | (n1 a) (n3 a) = 2 | otherwise = 1 where a = (n1 + n2 + n3)/3 i get an error message Instance of Fractional Int required for definition of howMany The problem is that since Haskell knows that n1 et al is an Int, it deduces that a must be an Int (since () compares values of the same type). Unfortunately, you're dividing with (/), which provides fractional answers, and not necessarily integers, and certainly not Ints. The easy way out is to consider a different division operator, but you may want to consider the behaviour of your program in the obvious borderline case. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Extensible downcasts impossible in Haskell? (was Re: Monomorphism, monomorphism...)
Tue, 9 Oct 2001 10:50:19 +1300, Tom Pledger [EMAIL PROTECTED] pisze: I'm curious about this impossibility. - Is it well known? If so, would someone please refer me to a paper or posting which explains it? I don't know. I'm not even sure if some clever encoding couldn't express it, but I can't imagine how it could do it and I would guess that it's impossible. It's not easy to formulate the question precisely but I'm quite sure that it's a well defined problem. You want to be able to embed arbitrary Haskell types in subtypes. So it doesn't suffice to make a universal type with many useful concrete types under constructors, which emulates dynamically typed languages with a fixed number of types like Lisp or Erlang (I think). Because an interface of abstract types not included in this set may have binary methods or alike, so you can't just wrap the interface in a tuple of functions with types taken from the included set only. - Does it just affect Haskell 98, or does it have deep implications for any future language extensions? IMHO it's independent from most extensions. The only extension I know of which could be used for implementing downcasts is Dynamic. Some extensible algebraic types (where definition of constructors is spread among an open set of modules) would allow downcasts too I think. - How does it relate to the alternative record mechanism idea you mentioned a while ago? http://haskell.org/pipermail/haskell/2000-December/000213.html My mechanism doesn't allow downcasts, although it promotes a style of programming which probably wants to use downcasts sometimes. It's described as a translation to Haskell 98 with multiparameter classes, fundeps, the ability to gather label names from all modules and associate each name with an unique class, and some small adjustments of the type system (related to the termination of typechecking). These extensions don't provide anything useful for implementing downcasting, so I couldn't implement downcasts without changing the compiler even if I specified them somehow. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
trouble with excercise 5.26 fibtable
im having abit of difficulty doing excersise 5.26 .. possible for an assistance plz :) _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Monomorphism, monomorphism...
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes: Since OO languages often use subtypes to emulate constructors of algebraic types, they need downcasts. In Haskell it's perhaps less needed but it's a pity that it's impossible to translate an OO scheme which makes use of downcasts into Haskell in an extensible way (algebraic types are closed). I agree. The TREX paper from Mark Jones and Benedict Gaster (I hope I have the names right) had both extensible records and extensible variants (extensible variants being what you would need to implement downcasts), but only the extensible records part of the paper was implemented in Hugs. Carl Witty ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Unicode support
On Tue, Oct 09, 2001 at 12:37:27PM +0200, Kent Karlsson wrote:
At 2001-10-09 02:58, Kent Karlsson wrote:
In summary:
code position (=code point): a value between and 10.
Would this be a reasonable basis for Haskell's 'Char' type?
Yes. It's essentially UTF-32, but without the fixation to 32-bit
(21 bits suffice). UTF-32 (a.k.a. UCS-4 in 10646, yet to be limited
to 10 instead of 31(!) bits) is the datatype used in some
implementations of C for wchar_t. As I said in another e-mail,
if one does not have high efficiency concerns, UTF-32 is a rather
straighforward way of representing characters.
I think that perhaps space efficiency concerns are moot anyway since
Char's would probably be represented by possibly evaluated thunks anyway
which I can't imagine being smaller than a pointer in general so for
haskell the simplification of UTF-32 is most likely worth it.
If space efficiency is a concern than I imagine people would want to use
mutable arrays of bytes or words anyway (perhaps mmap'ed from a file)
and not haskell lists of Chars.
At some point
perhaps there should be a 'Unicode' standard library for Haskell. For
instance:
encodeUTF8 :: String - [Word8];
decodeUTF8 :: [Word8] - Maybe String;
encodeUTF16 :: String - [Word16];
decodeUTF16 :: [Word16] - Maybe String;
data GeneralCategory = Letter_Uppercase | Letter_Lowercase | ...
getGeneralCategory :: Char - Maybe GeneralCategory;
There is not really any Maybe just there. Yet unallocated code
positions have general category Cn (so do non-characters):
Cs Other, Surrogate
Co Other, Private Use
Cn Other, Not Assigned (yet)
...sorting searching...
...canonicalisation...
etc. Lots of work for someone.
Yes. And it is lots of work (which is why I'm not volonteering
to make a qick fix: there is no quick fix).
I think a cannonical way to get at iconvs ('man 3 iconv' for info.)
functionality in one of the standard librarys would be great. perhaps I
will have a go at it. even if the underlying platform does not have
iconv then some basic conversions (utf8, utf16, latin1, [Char]) could
easily be provided with the same API and minimal implementation effort.
John
--
---
John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED]
---
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Extensible downcasts impossible in Haskell?
Thanks for the further explanation, Marcin. If I understand
correctly, you're talking about explicitly named algebraic types, not
just unions where the type is an anonymous reflection of the structure
as in:
Var (foo :: Int, bar :: Char)
-- in the style of A Polymorphic Type System for Extensible
-- Records and Variants (Gaster Jones)
and:
Either Int (Either Char ())
-- in the extensible union type mechanism of Monad Transformers
-- and Modular Interpreters (Liang, Hudak Jones)
I've sometimes wondered whether it would be appropriate to implement
the summing aspect of `data' by wrapping `newtype' around such
extensible variants. (There'd still need to be some construct for the
other aspects of `data': products and strictness flags.) For example,
this:
data T a b = T1 a !Int
| T2 b
could translate to something like this:
newtype T a b = T {unT :: Var (t1 :: (a, !Int),
t2 :: b)}
Then there'd be a way to extract a value of a structurally named type
from a value of an explicitly named type. Would this help to combine
explicitly named types with add-a-field subtyping and remove-a-summand
subtyping? For that matter, is it how O'Hugs already works beneath
the surface?
Regards,
Tom
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
help for excersise 5.13
i have done the function for borrowers but having some trouble with the borrowed and numBorrowed function. I have listed my code below with the borrowed function not completed and numBorrowed also not completed.Can you plz try to fill in the borrowed and numBorrowed functions if you can THANKS. type Database = [(Person,Book)] type Person = String type Book = String exampleBase :: Database exampleBase = [(Alice,Tintin),(Anna,little Women),(Alice,Asterix),(Rory,Tintin)] borrowers :: Database - Book - [Person] borrowers db findBook = [person|(person,bks)-db,bks==findBook] borrowed :: Database - Book - Bool borrowed db bookName numBorrowed :: Database - Person - Int reference from the craft of func programming second edition book page 84 and 87 _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Import Chasing Problems - hello.lhs
Hi Mike, Sigbjorn, Simon, Thanks so much for the pointers. Sigbjorn's suggestion to check out the patch was what finally fixed my problem. BTW, ghci still does work for me. I get this lovely message: F:\stuffghci -package win32 hello.lhs C:\ghc-5.02\bin\ghc.exe: file `P?B' does not exist The ? is acutally a spade symbol in my command window. Anyway, I hope that stops the stupid complaints from my direction for a while. And now I know what and where I should be looking for the bug list. SourceForge has just enough of a bug list to fool me into thinking that's where I should be looking. Thanks Again, John Heron Sigbjorn Finne wrote: John Heron [EMAIL PROTECTED] writes: I just installed ghc 5.02 on my NT 4.0 machine, and I'm wondering if the import chasing is broken for ghc-5.02 on Windows NT? Or perhaps there is yet another thing I don't understand about Haskell's environment or modules? I got the following complaints when trying to compile Sigborn Finne's Win32 example hello.lhs (http://www.dcs.gla.ac.uk/~sof/hello.lhs): F:\stuffghc -o hello hello.lhs hello.lhs:14: failed to load interface for `Win32': Could not find interface file for `Win32' ... Hi, have a look at the top of that file - it tells you what options you need to feed GHC to compile the example (well, the options it suggests are deprecated by The Powers That Be; you ought to use -package instead of -syslib). Simpler yet, try running it via ghci: c:\src\haskell ghci -package win32 hello.lhs and then evaluate 'main'. hth --sigbjorn btw, notice that ghc-5.02 currently has got a problem or two with the Win32 library -- see http://www.haskell.org/pipermail/glasgow-haskell-bugs/2001-October/000816.ht ml ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Unicode support
[Posted to haskell-cafe, since it's getting quite off topic] Kent Karlsson [EMAIL PROTECTED] writes: for a long time. 16 bit unicode should be gotten rid of, being the worst of both worlds, non backwards compatable with ascii, endianness issues and no constant length encoding utf8 externally and utf32 when worknig with individual characters is the way to go. I totally agree with you. Now, what are your technical arguments for this position? (B.t.w., UTF-16 isn't going to go away, it's very firmly established.) What's wrong with the ones already mentioned? You have endianness issues, and you need to explicitly type text files or insert BOMs. An UTF-8 stream limited to 7-bit ASCII simply is that ASCII stream. When not limited to ASCII, at least it avoids zero bytes and other potential problems. UTF-16 will among other things, be full of NULLs. I can understand UCS-2 looking attractive when it looked like a fixed-length encoding, but that no longer applies. So it is not surprising that most people involved do not consider UTF-16 a bad idea. The extra complexity is minimal, and further surfaces rarely. But it needs to be there. It will introduce larger programs, more bugs, lower efficiency. BMP characters are still (relatively) easy to process, and it saves memory space and cache misses when large amounts of text data is processed (e.g. databases). I couldn't find anything about the relative efficiencies of UTF-8 and UTF-16 on various languages. Do you have any pointers? From a Scandinavian POV, (using ASCII plus a handful of extra characters) UTF-8 should be a big win, but I'm sure there are counter examples. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode support
- Original Message - From: Ketil Malde [EMAIL PROTECTED] ... for a long time. 16 bit unicode should be gotten rid of, being the worst of both worlds, non backwards compatable with ascii, endianness issues and no constant length encoding utf8 externally and utf32 when worknig with individual characters is the way to go. I totally agree with you. Now, what are your technical arguments for this position? (B.t.w., UTF-16 isn't going to go away, it's very firmly established.) What's wrong with the ones already mentioned? You have endianness issues, and you need to explicitly type text files or insert BOMs. You have to distinguish between the encoding form (what you use internally) and encoding scheme (externally). For the encoding form, there is no endian issue, just like there is no endian issue for int internally in your program. For the encoding form there is no BOM either (or rather, it should have been removed upon reading, if the data is taken in from an external source). But I agree that the BOM (for all of the Unicode encoding schemes) and the byte order issue (for the non-UTF-8 encoding schemes; the external ones) are a pain. But as I said: they will not go away now, they are too firmly established. An UTF-8 stream limited to 7-bit ASCII simply is that ASCII stream. Which is a large portion of the raison d'être for UTF-8. When not limited to ASCII, at least it avoids zero bytes and other potential problems. UTF-16 will among other things, be full of NULLs. Yes, and so what? So will a file filled with image data, video clips, or plainly a list of raw integers dumped to file (not formatted as strings). I know, many old utility programs choke on NULL bytes, but that's not Unicode's fault. Further, NULL (as a character) is a perfectly valid character code. Always was. I can understand UCS-2 looking attractive when it looked like a fixed-length encoding, but that no longer applies. So it is not surprising that most people involved do not consider UTF-16 a bad idea. The extra complexity is minimal, and further surfaces rarely. But it needs to be there. It will introduce larger programs, more bugs True. But implementing normalisation, or case mapping for that matter, is non-trivial too. In practice, the additional complexity with UTF-16 seems small. , lower efficiency. Debatable. BMP characters are still (relatively) easy to process, and it saves memory space and cache misses when large amounts of text data is processed (e.g. databases). I couldn't find anything about the relative efficiencies of UTF-8 and UTF-16 on various languages. Do you have any pointers? From a Scandinavian POV, (using ASCII plus a handful of extra characters) UTF-8 should be a big win, but I'm sure there are counter examples. So, how big is our personal hard disk now? 3GiB? 10GiB? How many images, mp3 files and video clips do you have? (I'm sorry, but your argument here is getting old and stale. Very few worry about that aspect anymore. Except when it comes to databases stored in RAM and UTF-16 vs. UTF-32 which is guaranteed to be wasteful.) Kind regards /kent k ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode support
Kent Karlsson [EMAIL PROTECTED] writes: You have endianness issues, and you need to explicitly type text files or insert BOMs. You have to distinguish between the encoding form (what you use internally) and encoding scheme (externally). Good point, of course. Most of the arguments apply to the external encoding scheme, but I suppose it wasn't clear which of them we were discussing. But as I said: they will not go away now, they are too firmly established. Yep. But it appears that the right choice for external encoding scheme would be UTF-8. When not limited to ASCII, at least it avoids zero bytes and other potential problems. UTF-16 will among other things, be full of NULLs. Yes, and so what? So, I can use it for file names, in regular expressions, and in whatever legacy applications that expect textual data. That may be worthless to you, but it isn't to me. So will a file filled with image data, video clips, or plainly a list of raw integers dumped to file (not formatted as strings). But none of these pretend to be text! True. But implementing normalisation, or case mapping for that matter, is non-trivial too. In practice, the additional complexity with UTF-16 seems small. All right, but if there are no real advantages, why bother? I couldn't find anything about the relative efficiencies of UTF-8 and UTF-16 on various languages. So, how big is our personal hard disk now? 3GiB? 10GiB? How many images, mp3 files and video clips do you have? (I'm sorry, but your argument here is getting old and stale. Don't be sorry. I'm just looking for a good argument in favor of UTF-16 instead of UTF-8, and size was the only possibility I could think of offhand. (And apparently, the Japanese are unhappy with the 50% increase UTF-8's three-byte encoding over UTF-16's two-byte one) You could run the same argument against UTF-16 vs UTF-32 as internal encoding form, memory and memory bandwidth is getting cheap these days, too, although memory is still a more expensive resource than disk. But as (I assume) the internal encoding form shouldn't matter (as) much, as it would be hidden from everybody but the Unicode library implementor. It boils down to performance, which can be measured. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Reasons behind the one instance per type limitation
On Mon, 8 Oct 2001 15:03:15 -0700 Ashley Yakeley [EMAIL PROTECTED] wrote: At 2001-10-08 09:27, Diego Dainese wrote: what are the reasons behind the rule stating that a type must not be declared as an instance of a particular class, more than once in the program? It's so that the members of the class are unambiguous. -- class C t where foo :: t - Integer instance C Bool where foo _ = 3; instance C Bool where foo _ = 5; ambiguous = foo True; -- OK, this is reasonable; but why are instance declarations always automatically exported and imported across modules boundary? This goes against information hiding. Consider this situation: module M(T, f, g) where data T = ... ... module N where import M instance Eq T where ... now, suppose that in a second revision of the module M, an instance of Eq is made for T; even if this instance is needed for internal use only, it outlaws the instance defined in the module N. I think this problem could be a real show-stopper for big programs... Why aren't instance declarations handled by the module system like every other symbol, so that a module can decide when to import an instance declaration and when to export it? Are there technical difficulties with this approach? GHC has a flag that will turn the rule off. I cannot find it! -- Diego To reply remove the 2 `x' from the address. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Reasons behind the one instance per type limitation
hello, Why aren't instance declarations handled by the module system like every other symbol, so that a module can decide when to import an instance declaration and when to export it? Are there technical difficulties with this approach? i beleive the reason is that instances don't have names and the module system deals with names. on the other hand i don't think this is a very good reason and completely agree with you that it is a problem. i think some work is being done on introducing named instances to Hasekll (there was a paper in the Haskell workshop i think). bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
= vs -
What is the rationale for when Haskell demands a = and when it demands a -? Ideas that occur to me are: (a) The distinction helps the parser a lot (b) There's a semantic difference that the language's grammar is trying to express that isn't obvious to me -- Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Unicode support
Title: RE: Unicode support -Original Message- From: Ketil Malde [mailto:[EMAIL PROTECTED]] ... But as I said: they will not go away now, they are too firmly established. Yep. But it appears that the right choice for external encoding scheme would be UTF-8. You're free to use any one of UTF-8, UTF-16(BE/LE), or UTF-32(BE/LE). And you should be prepared for those encodings from anyone else. In some cases, like e-mail, only UTF-8 (unless encoded by base64) can be used for Unicode. When not limited to ASCII, at least it avoids zero bytes and other potential problems. UTF-16 will among other things, be full of NULLs. Yes, and so what? So, I can use it for file names, Millions of people do already, including me. Most of them don't even know about it. (The file system must be made for that, of course, but at least two (commonly used) file system use UTF-16 for *all* [long] file names: NTFS and HFS+. There is another file system, UFS, that uses UTF-8, with the names in normal form D(!), for all file names. (If the *standard* C file API is used, some kind of conversion is triggered.) Those file systems got it right, many other file systems are at a loss when it comes to even that simple level of I18N, rendering non-pure-ASCII file names essentially useless, or at least unreliable.) in regular expressions, If the system interpreting the RE is UTF-16 enabled, yes, of course. and in whatever legacy No: in modern systems. One of the side effects of the popularity of XML is that support for both UTF-8 and UTF-16 (also as external encodings) is growing... B.t.w. Java source code can be in UTF-8 or in UTF-16, as well as in legacy encodings. Unfortunately the compiler has to be steered via a command line parameter, while having the source files self declare their encoding would be much better (compare XML). applications that expect textual data. So will a file filled with image data, video clips, or plainly a list of raw integers dumped to file (not formatted as strings). But none of these pretend to be text! How is that relevant? If you're going to do anything higher-level with text, you have to know the encoding, otherwise you'll get lots of more or less hidden bugs. Have you ever had any experience with any of the legacy multibyte encodings used for Chinese/Japanese/etc.? In many of them, if you hit a byte that might be an ASCII letter, it need not be that at all, just a second byte component in the representation of a non-ASCII character. If you think every A byte is an A (an interpret them in some special way, say a (part of a) command name), you're in trouble! Often hard-to-find trouble. No-one that argues that one can take text in any ASCII extension and look at the (apparent) ASCII only (and everything else to be in some arbitrary extension, never affecting the processing) seems to be aware of the details of those encodings. B.t.w. video clips (and images) can and do have Unicode (UTF-16?) texts as components (e.g. subtitles). True. But implementing normalisation, or case mapping for that matter, is non-trivial too. In practice, the additional complexity with UTF-16 seems small. All right, but if there are no real advantages, why bother? Efficiency (and backwards compatibility) is claimed from people who work much more in the trenches with this than I do. And I have no quarrel with that. Kind regards /kent k
SuSE 7.3
Está para sair a 22 de Outubro... até eu estou a ficar surpreendido com a evolução destes tipos. Qd penso do 1o Linux que instalei (à cerca de dois anos? - andava eu no 4o ano) sinto-me como aquelas velhas que dizem eu ainda sou do tempo..., err... em que tinha de andar a alterar XF86Config à unha para configurar a resolução default do monitor (Lembras-te Canelas? :) De instalação para instalação a distribuição da SuSE tem ficado mais fácil de instalar e configurar, e até mais bonita. O Kernel tem-se desenvolvido bastante bem e as Desktops nem se fala. Tudo junto dá um sistema excelente. Eles tentam passar a ideia de que a distribuição é excelente para empresas, assim como familias comuns... e se há algum tempo tinha as minhas reserva, agora começo a achar que isso já não é bem assim. Vamos lá ver no que é que dá o Star Office 6, ou como (a mais longo prazo) evoluirá o KOffice - já para não falar do Hancom Office parece espetacular (mas esse é comercial) http://www.suse.com/us/products/suse_linux/i386/new_features.html http://www.suse.com/us/products/suse_linux/i386/games.html:) J.A. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Opsss... Sorry (SuSE 7.3)
I just accidently sent a mail written in portuguese about SuSE 7.3. I'm really sorry, it will not happen again. My apologies J.A. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Reasons behind the one instance per type limitation
Iavor S. Diatchki wrote: hello, Why aren't instance declarations handled by the module system like every other symbol, so that a module can decide when to import an instance declaration and when to export it? Are there technical difficulties with this approach? i beleive the reason is that instances don't have names and the module system deals with names. on the other hand i don't think this is a very good reason and completely agree with you that it is a problem. i think some work is being done on introducing named instances to Hasekll (there was a paper in the Haskell workshop i think). This is actually quite messy. The first point that needs to be made is that instance code is invoked silently. Writing x==y invokes instance code, but there is no way to say which instance should be used, so it is important that there is precisely one instance declaration in scope for that class and type. The current definition of Haskell achieves this by insisting that there is only one such declaration on the whole progam, although earlier versions achieved it by more complex, and less convenient rules, that had the advantage that they could be checked locally, at module compile time. One could envisage other means, such as defining, by some new syntactic feature, which of the possible (named) instance declarations was to be used in a particular scope. Having different instance definitions in scope at different places can casue problems, as code would just use whichever was in scope where it was invoked. This is like the dynamic scope rules of early Lisp, which is not considered good design. An alternative is to treat instances as part of the static environment at declaration time, and include them in closures when functions are passed around or exported. This ensures that a named function always uses the same instance code for the same type, but still has problems. In a language with referential transparency, one should be able to replace a function call by its body code, with substitution of arguments, (I'm assuming top-level functions with no global variables). Instances behave like global variables, so calling an imported function which brings its instances with it will in general give different results from substitution of body code for the function, and getting whichever instance is in scope at the point of call. Personally, I don't like this prospect. --brian ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs -
At 2001-10-09 11:55, Mark Carroll wrote: What is the rationale for when Haskell demands a = and when it demands a -? What? Example please... -- Ashley Yakeley, Seattle WA ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs -
Mark Carroll [EMAIL PROTECTED] writes: On Tue, 9 Oct 2001, Ashley Yakeley wrote: At 2001-10-09 11:55, Mark Carroll wrote: What is the rationale for when Haskell demands a = and when it demands a -? Okay, I can't give you anything formal, but here's my intuitive understanding of things e.g. x :: Integer - Integer A function from and Integer to an Integer. Even more obvious if you have one more parameter: g :: Integer - Integer - Integer g takes an Integer and returns a function that takes an Integer and returns an Integer. Equals-assignment would be very non-intuitive here. I guess the same argument goes for lambdas \x - x*x maps *from* an x *to* its square. x 1 = 1 x 2 = 3 Function definitions use (=). I'm not sure I see any really compelling reason, except that it's the usual math syntax, and arrows would look weird, in particular with nullary definitions: c - 0 y a = case a of 1 - 1 2 - 3 z a | a == 1 = 1 | a == 2 = 3 It seems there's a predisposition for having exactly one (=) in function definitions. Perhaps one could have had a syntax like z a = | a == 1 - 1 | a == 2 - 3 instead, as it'd make it more consisten with the case, but I suppose there's a reason for it being the way it is. The case statement is an expression like any other, while I suspect the guards can only be used in function definitions like your 'z' example. By the way, if you read '=' as is assigned to, and '|' as where and '-' as gives, things mostly make sense, I think. (Note that there's also the back-arrow, used to draw from, e.g. in the IO Monad main = do x - readFile /etc/passwd putStr (map crack (lines x)) or list comprehensions primes = [ p | p - [2..], noDivides p primes] I suppose the difference from (=) assignment is reasonably clear.) Rambling on, -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
