RE: ghc misreports the error line
And note that no compiler/interpreter currently rejects a string containing a literal tab character. My working version of GHC does :-) Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: whitespace in strings (was ghc misreports the error line)
Malcolm Wallace wrote, answering me: On the contrary I'm glad to see that the Haskell standard is so sensible. I edit Haskell using XEmacs, and I don't want to have to do an octal or hexadecimal dump of my source code to determine whether a string contains a tab, newline, return, line feed, Unicode en-space (there are several funny Unicode space characters available) or whatever. Syntax colouring, or indeed careful visual inspection, is good enough to reveal the extent of a string literal. I don't see why a hex dump is required. It reveals the extent, but not the contents. It is an unfortunate fact that the layout system means that invisible spaces of various types can transform one valid program into another inequivalent valid program, Both tabs and newlines are visible to me. Adding _any_ character, whitespace or not, to a string literal changes a valid program to another valid program. I'm afraid I don't know what point you are trying to make here. Can you elucidate? I cannot distinguish between tabs and sequences of spaces just by their appearances. And adding vertical tabs, returns, linefeed and miscellaneous unicode spaces would make things even worse. Allowing newline in string literals is also a bad idea if you want any kind of intelligent error-recovery (admittedly lacking in GHC and Hugs), since if you miss out a character the lexer has no way of recovering until it hits EOF. It really isn't difficult to give a sensible error message when the close quote is missing. It is however difficult to do error-recovery. Possible perhaps, but writing error-correcting parsers is hard enough as it is without us making it more difficult. Personally, I quite like being able to embed newlines in string literals because it reduces the meta-character clutter in long sections of text (e.g. help messages). I don't really find it very hard typing main = putStrLn hello,\n\ \world This style also has the advantage of preserving indentation, as well as making it clear exactly what of the various end-of-line characters (return, linefeed, formfeed, newline or whatever) is being printed. And note that no compiler/interpreter currently rejects a string containing a literal tab character.`` No Haskell compiler that I know of does error-recovery on lexing or parsing. But they should, in my opinion. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Problem with xargs and ar
Hello. Just a nasty build bug with 5.02 that I encountered. When building the prelude library, the individual object files are turned to an archive with xargs ar q libHSstd.a. Now, for some reason, on this system, GNU ar fails at some point during this process. The standard solaris ar works all right. Ar is not the issue here. I've probably blundered something with the installation of gnu ar, or it's buggy, or something. The problem is that once ar has failed, and the xargs has failed, and make has halted, an _incomplete_ libHSstd.a has been created. So one can just run make again, and compilation proceeds, since the libHSstd.a dependency has been satisfied. The way to fix this is of course just to build the archive to a temporary file, and once the xargs has completed successfully, rename it to libHSstd.a. Sorry for not being more verbose. I'm too tired from having fought for days trying to compile ghc with a _working_ ghci on this solaris machine... it took literally a minute to build hugs. :) Lauri Alanko [EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Socket library
as I have learnt now, there are problems with Sockets and ghc 5.02: http://haskell.org/pipermail/glasgow-haskell-users/2001-October/001008.html Unfortunately, I am currently working on WinNT and would not like to go back and install ghc4.08. Is there an easy way to patch this problem in my 5.02 installation. Sven Eric ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC Installation Location
Is there an easy way to get 'ghc' or one of the other binaries to tell me where the GHC installation directory is? I want to put the includes directory in a gcc -I flag in my makefile. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
gtk+hs and libgmp
When trying to compile the examples in gtk+hs, I get the following link errors: /opt/ghc/lib/ghc-5.02/libHSstd.a(PrelFloat__413.o): In function `shP2_2_alt': PrelFloat__413.o(.text+0x2b0): undefined reference to `__gmpz_cmp_si' etc.. When linking simple programs, this doesn't occur. I have the following gmp's installing: /usr/lib/libgmp.so.2.0.2 /usr/local/lib/libgmp.so.3.1.1 /opt/ghc/lib/ghc-5.02/libgmp.a It seems that the programs only link with the version in /usr/local/lib. I tried putting this path in 'library_dirs' for package 'gmp' in 'package.conf', but to no avail. Only when I explicitly put '/usr/local/lib/libgmp.so' in 'extra_ld_opts' for package 'gmp' did it work. -- Gérard Milmeister Tannenrauchstr. 35 8038 Zürich [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Socket library
In local.glasgow-haskell-users, you wrote: Unfortunately, I am currently working on WinNT and would not like to go back and install ghc4.08. Is there an easy way to patch this problem in my 5.02 installation. Maybe you're just lacking the Wintendo equivalent of /etc/protocols, but I don't know how Windows/cygwin handle these things. You could modify SocketPrim to use the number 6 instead of trying to do the getprotobyname lookup, but that's not a real remedy. -- Volker Stolz * [EMAIL PROTECTED] * PGP + S/MIME ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC Installation Location
Is there an easy way to get 'ghc' or one of the other binaries to tell me where the GHC installation directory is? I want to put the includes directory in a gcc -I flag in my makefile. On a Unix platform, the 'ghc' wrapper script contains the installation directory, which is passed as an option to the ghc-5.02 binary proper. On Windows platforms, there isn't a wrapper - ghc figures out the install location from the location of its binary. I've wondered at various times in the past whether there ought to be a link from /usr/local/includes/ghc to /usr/local/lib/ghc-5.02/includes. But the usual way around this problem is to use 'ghc' as your C compiler - then the -I flag gets injected automatically. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: gtk+hs and libgmp
When trying to compile the examples in gtk+hs, I get the following link errors: /opt/ghc/lib/ghc-5.02/libHSstd.a(PrelFloat__413.o): In function `shP2_2_alt': PrelFloat__413.o(.text+0x2b0): undefined reference to `__gmpz_cmp_si' etc.. When linking simple programs, this doesn't occur. I have the following gmp's installing: /usr/lib/libgmp.so.2.0.2 /usr/local/lib/libgmp.so.3.1.1 /opt/ghc/lib/ghc-5.02/libgmp.a It seems that the programs only link with the version in /usr/local/lib. I tried putting this path in 'library_dirs' for package 'gmp' in 'package.conf', but to no avail. Only when I explicitly put '/usr/local/lib/libgmp.so' in 'extra_ld_opts' for package 'gmp' did it work. The version in /opt/ghc/lib/ghc-5.02 should work, as should /usr/local/lib/libgmp.so.3.1.1. The version in /usr/lib looks like GMP 2, so that would cause the link errors. Make sure the link command line doesn't have -L/usr/lib on it, or at least not before -L/usr/local/lib and -L/opt/ghc/lib/ghc-5.02. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
qforeign-0.65: Bzip2: decompress hangs if data ends prematurely
Hello *, I found that decompress hangs if data ends prematurely, i.e. do content - readFile fp doSomething (Bzip2.decompress content) does not terminate in this case. Data that is corrupt in some other way (for example, decompressing a file that has not been generated with bzip2) is detected and an exception is thrown. Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Thread-Safety through FFI
It isn't safe to call foreign exported functions from more that one OS thread simultaneously. OK, can I call a foreign exported function from some other thread while the main thread is in 'foreign import' native code? I could have calls to the foreign exported function block until the main thread called a special foreign imported 'yield' function. This might work, but no guarantees. Make sure that at least the foreign import yield doesn't have an unsafe annotation. The reason I'm slightly worried is that the RTS isn't written to be used in a threaded environment - it doesn't use thread-friendly library calls, and I don't even want to think about signal handling. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC Installation Location
At 2001-10-25 03:01, Simon Marlow wrote:
I've wondered at various times in the past whether there ought to be a
link from /usr/local/includes/ghc to /usr/local/lib/ghc-5.02/includes.
Won't help, my GHC is installed at /usr/lib/ghc-5.02/, exactly where the
Debian package put it. And now that location is hard-coded in my Makefile.
But the usual way around this problem is to use 'ghc' as your C compiler
- then the -I flag gets injected automatically.
GHC didn't seem to want to compile my .cpp file -- instead it quietly and
successfully did nothing. Also I had to do this:
extern C {
#include Rts.h
}
...which I've recently entered a bug in SourceForge about.
--
Ashley Yakeley, Seattle WA
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Existential Typing (was Multi-parameter OOP)
Leon Smith wrote: [snip] If GHC had true existential typing, as opposed to just existential datatypes, you could reasonably code what I think you want like this: class A a where basicA :: Bool nextA :: a - (EX a'. A a' = a') basicA = True nextA = id data WrappedA = forall a. A a = WrappedA a instance A WrappedA where basicA = False nextA (WrappedA a) = a data A1 = A1 instance A A1 --... similarly for B ... class AB a b where toBool :: a - b - Bool instance (A a, B b) = AB a b where toBool a b | (basicA :: a) (basicB :: b) = True | (basicA :: a) || (basicB :: b) = False | otherwise = toBool (nextA a) (nextB b) [snip] Either I've missed something, or this isn't what I wanted. The problem I have is that AB is not extensible. If you want to add a new instances A2,B2 of A,B and a new definition of toBool which just works for A2 and B2, you can't do it, without changing the definition of toBool in the above instance. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Profiling in GHC-4.08.1
Andre W B Furtado writes: I was trying to compile a .hs file with the profiling option enabled (-prof -auto-all) but I got an error message: /usr/bin/ld: cannot find -lHSstd_p_imp collect2: ld returned 1 exit status Does anyone know what is this -lHSstd_p_imp? I am using GHC-4.08.1 (with Cygwin) under a Windows 98 platform. You're trying to use profiling with dynamic compilation. You can't, since there are no profiling DLLs, so use -static. -- http://sc3d.org/rrt/ | Analogy is a midwife, identity a murderer ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC Installation Location
At 2001-10-25 03:01, Simon Marlow wrote:
I've wondered at various times in the past whether there
ought to be a
link from /usr/local/includes/ghc to
/usr/local/lib/ghc-5.02/includes.
Won't help, my GHC is installed at /usr/lib/ghc-5.02/,
exactly where the
Debian package put it. And now that location is hard-coded in
my Makefile.
But the usual way around this problem is to use 'ghc' as
your C compiler
- then the -I flag gets injected automatically.
GHC didn't seem to want to compile my .cpp file -- instead it
quietly and
successfully did nothing.
Yes, I guess GHC should really understand C++ file suffixes.
Also I had to do this:
extern C {
#include Rts.h
}
Thanks, I'll look into fixing that.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Thread-Safety through FFI
This might work, but no guarantees. OK, so I'd be better off making sure all Haskell runs in one OS-thread. My concerns still apply - non-thread-friendly library calls may mean that GHC's RTS interacts badly with the rest of your threaded program. Although presumably I can use Haskell-threads: I can have a special Haskell-thread that handled a queue of incoming execution requests, firing off a new Haskell-thread for each one. And then I could have a native-code mechanism to allow asynchronous additions to the queue. Yes, there's no restriction on using Haskell threads because they're handled internally by the RTS. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: gtk+hs and libgmp
On Thu, 2001-10-25 at 12:04, Simon Marlow wrote: The version in /opt/ghc/lib/ghc-5.02 should work, as should /usr/local/lib/libgmp.so.3.1.1. The version in /usr/lib looks like GMP 2, so that would cause the link errors. Make sure the link command line doesn't have -L/usr/lib on it, or at least not before -L/usr/local/lib and -L/opt/ghc/lib/ghc-5.02. Cheers, Simon I tried to remove the libgmp.so from both /usr/local/lib and /usr/lib. ghc doesn't seem to link with the one in /opt/ghc. Also when I give /opt/ghc/lib/ghc-5.02/libgmp.a on the command line it doesn't work... It only works with /usr/local/lib/libgmp.so. I guess, that gmp is always used, so I wonder that it works apart from gtk+hs. -- Gérard Milmeister Tannenrauchstr. 35 8038 Zürich [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: gtk+hs and libgmp
On Thu, 2001-10-25 at 12:04, Simon Marlow wrote: The version in /opt/ghc/lib/ghc-5.02 should work, as should /usr/local/lib/libgmp.so.3.1.1. The version in /usr/lib looks like GMP 2, so that would cause the link errors. Make sure the link command line doesn't have -L/usr/lib on it, or at least not before -L/usr/local/lib and -L/opt/ghc/lib/ghc-5.02. Cheers, Simon I tried to remove the libgmp.so from both /usr/local/lib and /usr/lib. ghc doesn't seem to link with the one in /opt/ghc. Also when I give /opt/ghc/lib/ghc-5.02/libgmp.a on the command line it doesn't work... It only works with /usr/local/lib/libgmp.so. I guess, that gmp is always used, so I wonder that it works apart from gtk+hs. It seems very strange that the libgmp in your GHC installation doesn't work. How did you install GHC? Do you have problems linking other programs, or just gtk+hs programs? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Installation Location
Is there an easy way to get 'ghc' or one of the other binaries to tell me
where the GHC installation directory is? I want to put the includes
directory in a gcc -I flag in my makefile.
For ghc = 5.00, but not on Windows:
#!/bin/sh
GHCDIR=`grep '^libdir' ${whichGHC} | head -1 | sed 's/^libdir=.\(.*\)./\1/'`if
[ ! -d $GHCDIR/imports ]
then GHCDIR=`grep '^TOPDIROPT' ${whichGHC} | head -1 | sed
's/^TOPDIROPT=*-B\([^;]*\).*/\1/'`
fi
echo $GHCDIR/imports
For ghc 5.00, including on Windows:
#!/bin/sh
GHCDIR=`grep '^\$libdir=' ${whichGHC} | head -1 | sed
's/^\$libdir=[^/]*\(.*\).;/\1/'`
if [ -d $GHCDIR/imports ]
then echo $GHCDIR/imports
elif [ -d $GHCDIR/lib/imports ]
then echo $GHCDIR/lib/imports
echo echo unknown
fi
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Help with cygwin and ghc
I would like to request help concerning the installation of ghc to cygwin. I have tried the websites, and they didn't work, as it didn't let me compile. Thank you
Re: GHC Installation Location
On Thu, Oct 25, 2001 at 03:18:33 -0700, Ashley Yakeley wrote: At 2001-10-25 03:01, Simon Marlow wrote: I've wondered at various times in the past whether there ought to be a link from /usr/local/includes/ghc to /usr/local/lib/ghc-5.02/includes. Won't help, my GHC is installed at /usr/lib/ghc-5.02/, exactly where the Debian package put it. And now that location is hard-coded in my Makefile. What about (finally!) adding the `--print-include-path' and `--print-library-path' switches to ghc? That would be a clean solution, IMO. IIRC, this has been asked for several times in the past, but was never implemented. I guess it would make at least Malcolm's life much easier for the nhc98 scripts... :) Cheers, Michael -- /~\ ASCII ribbon | inbox, n.: \ / campaign |A catch basin for everything you don't want to deal X against |with, but are afraid to throw away. / \ HTML mail| ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: qforeign-0.65: Bzip2: decompress hangs if data ends prematurely
Thu, 25 Oct 2001 12:06:53 +0200 (CEST), Michael Marte [EMAIL PROTECTED] pisze: I found that decompress hangs if data ends prematurely, i.e. do content - readFile fp doSomething (Bzip2.decompress content) does not terminate in this case. Try this patch (sorry, untested): --- examples/Bzip2.hsc~ Mon Jun 11 23:19:50 2001 +++ examples/Bzip2.hsc Thu Oct 25 17:55:19 2001 @@ -169,6 +169,7 @@ let blockIn = take blockSize input ok - decompressBlock strm blockIn blockSize case ok of +RunOk 0 [] - ioError (userError bzip2: premature end of +compressed data) RunOk inSize blockOut - liftM (blockOut++) $ unsafeInterleaveIO $ decompressLoop strm (drop inSize input) StreamEnd output - return output It's in CVS at SourceForge now. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reading files via http or ftp
Has anyone used the Socket library to read files specified via an http and/or ftp URL? -- Colin Paul Adams Preston Lancashire ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fwd: Can I install HOpenGL in Windows?
* Denver [EMAIL PROTECTED] [2001-10-26T01:25+1000]: Please help. I would like to use HOpenGL within Windows, so I wanted to ask whether it was possible, and if it is, I would like to request for help. Any help greatly appreciated. Hi! I'm sorry, I don't know much about the Windows port of GHC, but I'm sure the folks at [EMAIL PROTECTED] can be of some help, or maybe the author of HOpenGL can step in... [Sven, AYT? =)] I'll do a Cc: to the list. To subscribe to any of the GHC mailing lists, please visit http://haskell.org/ghc/mailing-lists.html Cheers, Michael ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC Installation Location
At 2001-10-25 03:18, Ashley Yakeley wrote: I've wondered at various times in the past whether there ought to be a link from /usr/local/includes/ghc to /usr/local/lib/ghc-5.02/includes. Won't help, my GHC is installed at /usr/lib/ghc-5.02/, exactly where the Debian package put it. Actually I suppose this means I could write #include ghc/Rts.h At 2001-10-25 09:05, Mieszko Lis wrote: I'm not sure this would be so good when you want to have two versions of ghc installed on the same machine... Currently the Debian ghc5 package installs links such as /usr/bin/ghc using the 'alternatives' system. You'd just need to add a /usr/include/ghc one to that alternatives group. -- Ashley Yakeley, Seattle WA ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Installation Location
On Thu, Oct 25, 2001 at 04:45:13PM -0700, Ashley Yakeley wrote: I'm not sure this would be so good when you want to have two versions of ghc installed on the same machine... Currently the Debian ghc5 package installs links such as /usr/bin/ghc using the 'alternatives' system. You'd just need to add a /usr/include/ghc one to that alternatives group. Right, but if all ghcs always use /usr/include/ghc then you can only run the ghc that is the `current alternative' -- if you try to run the other one, it will find the wrong libraries (which may or may not work). So, without root intervention to change the current alternative, you could still only run one, which makes having multiple versions installed a lot less useful. And, even if ghc itself did not use /usr/include/ghc, your multilingual makefile would get the wrong includes if you used the non-current-alternative ghc. -- Mieszko ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Incoherence
John Hughes wrote: What we need is different binding syntax for monomorphic and polymorphic bindings. Roll on := and = ... I agree absolutely that we need such a distinction. Although it's worth clarifying a point. The monomorphism restriction doesn't exclude polymorphism, just overloading, e.g. I can bind `x = []' with no problem. So is your proposal to have := bind non-overloaded (and non-implicitly parameterized terms), or do you really mean that it will only bind monomorphic terms? (thus `x := []' would be problematic, unless there's a type sig). --Jeff My proposal is that := should bind *monomorphically* -- just like lambda binding. The motivation for that is that a polymorphic function can easily become overloaded after a small change to the program, such as adding removal of duplicate elements from a list. Such changes shouldn't cause wholesale differences in typing -- which the MR currently can. Another way to look at it is that = should imply type generalisation (including qualification), and := should mean no generalisation. It's a little odd to support *two kinds* of generalisation (with and without qualification). `x := []' wouldn't be problematic, just monomorphic. That is, x must be used consistently as a list of a particular type. But that need not prevent the type that x has from being inferred from its uses. John ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Incoherence
John Hughes wrote: | `x := []' wouldn't be problematic, just monomorphic. | That is, x must be used consistently as a list of a | particular type. Just to check if I understand you correctly. In your proposal, does the following thing share `x'? let x = fac 100 in x + x (My understanding is that, in order to do this in your proposal, we have to say: let x := fac 100 in x + x Correct?) Does this also mean that it becomes impossible to share polymorphic values? I.e. the following contrived example will not behave as usual: wrong :: Either String a wrong = Left (show (fac 100)) -- not shared? example1 :: Either String Int example1 := do wrong return 1 example2 :: Either String Char example2 := do wrong return 'a' (With the usual Either monad instance.) Of course, in this case, there is a perfect remedy, just lifting out `show (fac 100', which is a monomorphic expression. However, this is not always possible, we might have a datatype like this: data PolyMonoList a = Poly Int (Foo a) | Mono a (Foo a) | Nil We can construct rather large polymorphic values, which have to be converted in linear time to the same value of a different type. I guess we already have the problem of not being able to share monomorphic values polymorphically. In fact, the Either monad instance is a good example: instance Monad (Either e) where return = Right Left x = k = Left x Right a = k = k a In the definition of `=', it is impossible to share `Left x'. /Koen. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: rank 2-polymorphism and type checking
Hello, and thanks for the various answers! Martin Odersky writes: Simon, You are correct to have doubts. Indeed our system would not handle this case, as type variables can only be instantiated to monomorophic types, not to type schemes. The closest you can get to it is to wrap the instance type in a type constructor. I.e. `t' could be instantiated to T (\c. forall d . (c-d) - d - d) where T was declared newtype T = T (\c. forall d . (c-d) - d - d) But I guess that does not solve Janis's problem. I'm not sure whether it would. To make things more complicated, the application I had in mind would not only require a rank-3 type and quantification over a type constructor, but also polymorphic recursion. Hmm, I wanted to use the free theorem of g's type, but rethinking I wonder what this actually *means* in the presence of quantification over type constructors. The whole story got so complicated, because I wanted to use a nested type of the form data D a = ... | forall b . F (b - a) (D b) If I settle for the less general but still useful data D a = ... | F (a - a) (D a) then I can do without any extensions :-) Regards, Janis. -- Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Deprecated feature section
Hi! George Russel proposed a search for things which should be deprecated. I have a very distinct unfondness for contexts in algebraic data type declarations. They make absolutely no difference except move type errors to a different part of a program (or rather, they add type errors). In that sense they could be said to be quite harmless, but they dramatically complicate the typing rules for everything involving algebraic data types, especially when combined with labelled fields. Cheers, /kff ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Incoherence
Hi! The binding form := must absolutely have a completely monomorphic type. A while back I posted the result that the MR kills principal types in Haskell. The problem with the MR is exactly that it introduces types which may be polymorphic but not overloaded. So if we want to regain principal types, := must be completely monomorphic. What we could have is that := is allowed to be polymorphic if and only if an explicit type signature is given. I do not thing this would hurt principality, and we could still have Koen's example, but like this: wrong :: Either String a wrong := Left (show (fac 100)) -- shared and polymorphic due to signature! example1 :: Either String Int example1 := do wrong return 1 example2 :: Either String Char example2 := do wrong return 'a' How does that sound? /kff ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98: Enum Class
George Russell [EMAIL PROTECTED] writes: In addition, I suggest that, since it is widely agreed that the instances of Enum for Float and Double And (Ratio a)? are highly unsatisfactory -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: Haskell 98: Enum Class
Ketil Malde wrote: George Russell [EMAIL PROTECTED] writes: In addition, I suggest that, since it is widely agreed that the instances of Enum for Float and Double And (Ratio a)? Yes, you've got a point there. They'd none of 'em be missed. Of course mathematicians are well aware that rational numbers can be enumerated, just not the way the Haskell standard does it . . . ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell 98: Enum Class
| In addition, I suggest that, since it is widely agreed that | the instances of Enum for Float and Double are highly | unsatisfactory, the report should give these instances the | same status as n+k patterns have (in 1.4 of the recent | revision). In particular, their use should be discouraged, | and there | should be a warning that the instances may be altered or | removed in Haskell 2. | | It might clear the ground somewhat for Haskell 2 if there | were a new section containing a list of deprecated features; | we can probably think of some other things which should go in | there. In addition to what's said for n+k patterns, I | suggest the standard explicitly encourage (but not oblige) | conforming compilers to issue warnings when deprecated | features are used. The Revised Haskell 98 report is suppposed to be in conclusion mode. An attempt to decide what features are deprecated would open up a big new debate. One could instead list features which are controversial --- that would be easier. Whether it would actually be worth the work of getting consensus on such a list is not clear to me. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Haskell 98: Enum class
| Somebody raised the issue why to/fromEnum doesn't use Integer | instead of Int. This would, it would seem, solve at least | some of the Enum problems that arise from (integral) types | with more than 4G values. So, again, why not? There was an extended discussion on this point, I believe, during the Haskell 1.4 -- Haskell 98 transition. I forget the details, but I expect that efficiency was an issue. However, regardless of the merits of the case, changing the type of to/fromEnum is not a possibility for the Haskell 98 report, I'm afraid. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell 98: Enum Class
Simon Peyton-Jones wrote: [snip] The Revised Haskell 98 report is suppposed to be in conclusion mode. An attempt to decide what features are deprecated would open up a big new debate. One could instead list features which are controversial --- that would be easier. Whether it would actually be worth the work of getting consensus on such a list is not clear to me. I don't really understand what is meant by controversial. For n+k patterns we can summarise section 1.4 as saying (1) they are discouraged. (2) they may be altered or removed in a future version of Haskell. (3) implementors are encouraged to provide a mechanism for users to selectively enable or disable them. (Personally I would prefer warnings, but the difference isn't very important; in both cases the effect is to draw the users' attention to the use of deprecated features.) Now I think that, at least, the use of the instance of Enum Float/Double should also be like this. Does anyone actually disagree with this? Fortunately I am not responsible for revising the Haskell standard. I say fortunately, because there a very large number of things I would change if redesigning the language from scratch, and I might be tempted to try and sneak them into the current revision. In the current circumstances, I think the best we can do is try to identify those features which can safely be deprecated without upsetting a large body of users. n+k patterns are safely in there, and I think Enum Float/Double should be too. I think the suggestion that contexts in datatypes should also be on the list is a good one, since at the moment they do nothing useful, though a future change might more sensibly change them so that they do. I appreciate the problem if the Haskell98 revision has to be completed in the very near future. Is there a set timetable? I think we should be able to reach some conclusion on an agreed set of deprecated features in the next month at the worst. I wonder if we should make some kind of shared intensive effort to track down some of the remaining bugs in the Haskell standard. It's a bit unfair putting it all on SPJ's shoulders. I've already had a go at being pedantic with the lexing and layout sections. I don't mind doing the same with another few pages of the library or report, if some other people will do so too so we can debug the whole thing. Then perhaps we might be able to get the whole thing done by Christmas. George Russell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
HaXml article on IBM developerWorks
There's a nice article on HaXml (Runciman and Wallace's excellent Haskell toolkit for XML) in the XML Matters section in IBM developerWorks. From the abstract: | XML Matters : Transcending the limits of DOM, SAX, and XSLT | --- | Consider Haskell in lieu of DOM, SAX, or XSLT for processing XML data. The | library HaXml creates representations of XML documents as native recursive | data structures in the functional language Haskell. HaXml brings with it a | set of powerful higher order functions for operating on these datafied | XML documents. Many of the HaXml techniques are far more elegant, compact, | and powerful than the ones found in familiar techniques like DOM, SAX, or | XSLT. Code samples demonstrate the techniques. http://www-106.ibm.com/developerworks/xml/library/x-matters14.html --Joe English [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Incoherence
On Thursday 25 October 2001 07:21 am, John Hughes wrote: My proposal is that := should bind *monomorphically* -- just like lambda binding. The motivation for that is that a polymorphic function can easily become overloaded after a small change to the program, such as adding removal of duplicate elements from a list. Such changes shouldn't cause wholesale differences in typing -- which the MR currently can. Another way to look at it is that = should imply type generalisation (including qualification), and := should mean no generalisation. It's a little odd to support *two kinds* of generalisation (with and without qualification). `x := []' wouldn't be problematic, just monomorphic. That is, x must be used consistently as a list of a particular type. But that need not prevent the type that x has from being inferred from its uses. Another place where `:=' bindings are badly needed is the recursive do-notation (mdo, as supported in hugs.) In an mdo, let bindings have to be monomorphic, because they are passed back to the mfix loop in a lambda binding. Hence, if we had :=, we can simply say that mdo only allows let bindings of the `:=' form, and that would clear up the whole issue. I'm no expert, but I think the new proposal for the arrow notation, if it allows recursive binding forms, can make use of this facility as well. Just take this as another vote in favor of `:=' bindings. -Levent. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Incoherence
On Thu, Oct 25, 2001 at 09:47:31AM +, Levent Erkok wrote: Another place where `:=' bindings are badly needed is the recursive do-notation (mdo, as supported in hugs.) In an mdo, let bindings have to be monomorphic, because they are passed back to the mfix loop in a lambda binding. Hence, if we had :=, we can simply say that mdo only allows let bindings of the `:=' form, and that would clear up the whole issue. I'm no expert, but I think the new proposal for the arrow notation, if it allows recursive binding forms, can make use of this facility as well. Yes, let bindings in arrow notation must also be monomorphic, but it's nothing to do with recursion. It's because the value being defined is passed as input to the next arrow. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Incoherence
Thu, 25 Oct 2001 09:47:31 +, Levent Erkok [EMAIL PROTECTED] pisze: Another place where `:=' bindings are badly needed is the recursive do-notation (mdo, as supported in hugs.) In an mdo, let bindings have to be monomorphic, because they are passed back to the mfix loop in a lambda binding. Hence, if we had :=, we can simply say that mdo only allows let bindings of the `:=' form, and that would clear up the whole issue. It would be great to be able to write ':=' inside 'do' without 'let' because 'let' starts a new layout level and requires increased indentation when the definition doesn't fit in one line. -- __( 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
bug in displaying fixed numbers
I was very surprised when I discovered (writing a bit more complicated program) that a program like import Numeric ( floatToDigits ) print $ showFFloat Nothing 0.01 enters in to infinite loop. I found that (formatRealFloat FFFixed Nothing) do not like displaying numbers less than 0.1. For x = 0.01 we have e=-1 and ds=1. Function f loops down to 0, which will never be reached. I changed the function in hugs for my use. But since the problem is in a standard library I will have to make a workaround for may code to work elsewhere. Original and modified parts below. Original: FFFixed - case decs of Nothing - let f 0 s ds = mk0 s ++ . ++ mk0 ds f n s = f (n-1) (s++0) f n s (d:ds) = f (n-1) (s++[d]) ds mk0 = 0 mk0 s = s in f e ds Wish: FFFixed - case decs of Nothing - let f 0 s ds = mk0 s ++ . ++ mk0 ds f n s = f (n-1) (s++0) f n s (d:ds) = f (n-1) (s++[d]) ds g n ds = 0. ++ (replicate n '0') ++ ds mk0 = 0 mk0 s = s in if e = 0 then f e ds else g (-e) ds I am rather new to Haskell so I do not know if the problem have been discussed already. -- =*= Lukasz Pankowski =*= ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [ketil@ii.uib.no: Re: Enum class]
(I want to trim the headers, but don't know the history of this thread. Also cc:ed back to the Haskell list.) On Thu, Oct 25, 2001 at 11:11:42AM +0200, Ketil Malde wrote: Dylan Thurston [EMAIL PROTECTED] writes: I agree that Enum instances for Float/Double are not likely to be useful. From a gut feeling, I could see a use for expressions like [1.5, 1.6..] and [1.5, 1.6..2.0] (i.e. enumFromThen and enumFromThenTo) but enumFrom and enumFromTo making list of rounded integers seems strange to me. It seems to me that enumFromThen and -To could be implemented something like: enumFromThen beg next = beg : enumFromThen next (next+delta) where delta = next-beg similarly for enumFromThenTo, of course. i.e. depending only on functionality found in Num. Why not put these functions there, and remove Float and Double as Enum instances? What am I missing? Currently you can write data Day = Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday weekdays = [Monday..Friday] which has nothing to do with Num. Best, Dylan Thurston PGP signature
