Instances of type synonyms in ghc-3.02
When trying to compile the following module, ghc-3.02 dies with the
following message:
panic! (the `impossible' happened):
tcInstType:1
---
module Impossible where
type T a = Int
classC a where foo :: Int - IO a
instance C (T a) where foo = undefined
bar :: C a = IO a
bar = foo 12 = foo
---
Section 4.3.2 of the Haskell report (Instance Declarations) states:
The general form of the corresponding instance declaration is:
instance c' = C (T u1 ... uk) where { d }
where k=0 and T is not a type synonym.
Therefore, the above program is illegal (Hugs tells me this, too). But
things are even stranger when bar is removed:
---
module Impossible where
type T a = Int
classC a where foo :: Int - IO a
instance C (T a) where foo = undefined
---
ghc-3.02 happily compiles this. Bug or feature?
--
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne
Re: Beta versions?
Alastair Reid writes: [redirected to [EMAIL PROTECTED]] Arjan van Ijzendoorn (or is it Kees?) writes: I've a complete program written using Haskell (GHC 3.02) but I'm unable to load the program in Hugs (jan98, 1.4). I get an error that "showLitChar" is not defined. I could try to adjust the Hugs prelude file to include the definition of "showLitChar". It sounds like you've found a bug in GHC and a bug in Hugs: o showLitChar shouldn't be exported from the Prelude (ghc is wrong) o showLitChar should be exported from Char (Hugs is wrong) GHC only exports showLitChar via Char, so something else must be going on here.. --Sigbjorn
Re: ghc involked ld cannot msync ???
Guest account nr 2 writes: Hi, This is byron ([EMAIL PROTECTED]), and im at Chalmers this week, where im having a problem getting GHC 2.10 to work. here is the error msg: ld: fatal: file simulate: cannot msync file; errno=49 do you have any ideas? what is msync? If I remember correctly, the reason for this is due to the linker running out of space (the error no actually indicates that you've run out of disk quota...) Try adjusting your setting of TMPDIR (e.g., to ".") and have another go.. (If that doesn't do it, try getting a non-guest user to do the link for you and see if that helps.) --Sigbjorn
ghc involked ld cannot msync ???
Hi, This is byron ([EMAIL PROTECTED]), and im at Chalmers this week, where im having a problem getting GHC 2.10 to work. here is the error msg: ld: fatal: file simulate: cannot msync file; errno=49 do you have any ideas? what is msync? here is a full transcript: - + ghc -v -fglasgow-exts -cpp -optP-imacros -optP/users/cs/csguest2/hawk-1.3/lib/hawk-macros.h -O -fvia-C -O2-for-C -i/users/cs/csguest2/hawk-1.3/lib -i/users/cs/csguest2/hawk-1.3/lib/dlx -L/users/cs/csguest2/hawk-1.3/lib -L/users/cs/csguest2/hawk-1.3/lib/dlx -o simulate Components.o DisplayChip.o Main.o Processor.o Utils.o -lhawk -ldlx -lhawk The Glorious Glasgow Haskell Compilation System, version 2.10, patchlevel 0 Linker: gcc -v -u PrelBase_Z91Z93_closure -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u PrelBase_False_inregs_info -u PrelBase_True_inregs_info -u DEBUG_REGS -o simulate Components.o DisplayChip.o Main.o Processor.o Utils.o /usr/pd/lib/ghc-2.10/TopClosure.o -L/users/cs/csguest2/hawk-1.3/lib -L/users/cs/csguest2/hawk-1.3/lib/dlx -L/usr/pd/lib/ghc-2.10 -lhawk -ldlx -lhawk -lHS -lHS_cbits -lHSrts -lHSclib -lgmp -lm Reading specs from /usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.1/specs gcc version 2.7.2.1 /usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o simulate -u PrelBase_Z91Z93_closure -u PrelBase_IZh_static_info -u PrelBase_CZh_static_info -u PrelBase_False_inregs_info -u PrelBase_True_inregs_info -u DEBUG_REGS /usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.1/crt1.o /usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.1/crti.o /usr/ccs/lib/values-Xa.o /usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.1/crtbegin.o -L/users/cs/csguest2/hawk-1.3/lib -L/users/cs/csguest2/hawk-1.3/lib/dlx -L/usr/pd/lib/ghc-2.10 -L/usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.1 -L/usr/ccs/bin -L/usr/ccs/lib -L/usr/pd/gnu/lib Components.o DisplayChip.o Main.o Processor.o Utils.o /usr/pd/lib/ghc-2.10/TopClosure.o -lhawk -ldlx -lhawk -lHS -lHS_cbits -lHSrts -lHSclib -lgmp -lm -lgcc -lc -lgcc /usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.1/crtend.o /usr/pd/gnu/lib/gcc-lib/sparc-sun-solaris2.5.1/2.7.2.1/crtn.o ld: Software Generation Utilities (SGU) SunOS/ELF (LK-2.0 (S/I) - versioning) ld: fatal: file simulate: cannot msync file; errno=49 real 15.1 user5.4 sys 1.6 deleting... simulate rm -f /tmp/ghc14570* gmake: *** [simulate] Error 1
Some useful libraries
In recent weeks we have been organising and polishing our locally produced Haskell software. Most of this software was written for educational purposes, but may be quite useful for a wider audience. At: http://www.cs.ruu.nl/groups/ST/Software/index.html you can find links and information about the following modules and packages: HASKELL-RELATED * Pretty-Printing combinators A set of combinators for writing pretty printers, which are fast and user friendly and enable you to formulate in an intuitive way a set of alternative layouts to choose from. We did quite some polishing on this recently, so if you have a previous version please throw it away. * Parsing combinators A set of combinators for writing deterministic error-correcting parsers, which are fast and user friendly. With it you get a parametrisable scanner, too. Note that these combinators are completely different from the monadic style combinators of Hutton and Meijer. * ActiveHaskell, Haskell/COM integration * Partial evaluator You may have a look at this to see how to use the pretty printing and parser combinators. * Micro attribute system You may have a look at this to see how to use the pretty printing and parser combinators. OTHER SOFTWARE * LRC, attribute grammar system * Lilypond, music typesetter If you like something of the above or have comments please let us know. I am sure you will like at least some of it! Doaitse Swierstra -- PLEASE NOTE THAT THE DOMAIN NAME ruu HAS BEEN CHANGED TO uu I HONESTLY APOLOGIZE FOR THE INCONVENIENCES THIS CAUSES TO YOU, BUT IT HAS BEEN ENFORCED UPON US BY THE UNIVERSITY BOARD. The old domain will remain functioning for a long time, but you cannot say that you have not been warned. __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University (Prof. Dr)P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __
Re: circular module imports
Alex,
If I were you I'd dispense with "deriving(Read,Show)" in module Publisher,
and add an explicit instance for Read/Show on Publisher in PublisherDB.
That would solve your circularity problem.
Haskell does permit mutually recursive modules, but Hugs does not support
them, and GHC requires some help (described in the user manual; basically
you need to give it an "interface file" to get started).
Simon
I wanted to represent a reasonably small list of Publishers.
So I created:
module Publisher where
data Publisher = Publisher { name::String, func::Registration-Bool}
data Registration =
Registration { data::String, pub::Publisher} deriving (Read,Show)
Notice that the Publisher data type includes functions so I can't just
store these publishers as tuples in a database. Instead I store
information on each publisher in a file e.g. Yahoo.lhs CNN.lhs
DoubleClick.lhs
module Yahoo where
import Publisher
Yahoo = Publisher "Yahoo" (\x - x)
Another file, PublisherDB.lhs, imports each of these
module PublisherDB where
import Yahoo
import DoubleClick
publishers = [("Yahoo",Yahoo),("DoubleClick",DoubleClick)]
getPublishers::String - Publisher
getPublisher name = lookup publishers name
The trouble I have is that Registration requires me to define
read/show for Publisher and read/show requires access to getPublisher
which leads to a circular import problem:
* getPublisher needs to be defined in PublisherDB because it requires a
complete list of Publishers.
* PublisherDB imports each individual publisher (e.g. Yahoo, DoubleClick)
Individual publishers import Publisher
For literate programming reasons, as well as general program modularity
reasons, I would prefer not to merge all of these into a single large
file.
Is there another way?
-Alex-
___
S. Alexander Jacobson i2x Media
1-212-697-0184 voice 1-212-697-1427 fax
Re: Exceptions are too return values!
On Mon, 8 Jun 1998, S. Alexander Jacobson wrote: 1. it is not logically consistent to treat exceptions as return values A function cannot do anything but return a value, can it? For example, suppose that we define a new function: foo' a b = a + b -- foo' is strict in its arguments Our intuition is that foo' is commutative. foo' a b = foo' b a. But that turns out not to be true when you have exceptions. That's the problem with intuitions: they can be wrong... Anyhow, if one is to have exceptions procteting +, I don't think that commutativity of foo' is reasonable: to handle exceptions, you have to do checks, and that you can only do in one order or another. Take x and y from before, z = foo' x' y' What is the value of z? Haskell does not promise to evaluate arguments in any particular order so, depending on implementation, z may be either Exception DivideByZero or Exception NotFactorialDomain -1. Actually, using a monad to manage exceptions you can (maybe, have to) choose a definite order of evaluation of non-exceptionality-conditions. Truly exceptional conditions are those that truly are outside of the domain of the function being evaluated. e.g. factorial -1 The VALUE of (factorial -1) is not an exception. Neither is the value of (factorial (1 `div` 0)). When a function is passed bad arguments, it is not meaningful (from a functional perspective) to have it return a value. In a typed language, a function *cannot* be applied to something outside its domain. That's the whole point! The value of a function over arguments outside its domain is undefined. When such an event occurs, the logically consistent behavior is to exit function evaluation and tell the caller what was wrong with the arguments passed (to the extent it is possible to do). One can rightfully argue that, if one is willing to consider bottom (which is a value we cannot test for!) a return value, which we are, considering an exception a return value is *very* consistent. -- m --- Mariano Suarez Alvarez The introduction of Departamento de Matematica numbers as coordinates Universidad Nacional de Rosario [...] is an act of violence Pellegrini 250 A. Weyl 2000 Rosario - Argentina e-mail: [EMAIL PROTECTED] ---
Re: Exceptions are too return values!
Alex Jacobson:
Ooops, I forgot to remove the "and". Anyway, my point is that
1. it is not logically consistent to treat exceptions as return values
2. as an implementation matter it violates laziness to do so
OK, now I follow. And diagree. ;-) On your second point first:
I'm not sure what you mean by "violates laziness"; it would be true
to say that adding exceptional return values in a given way might
well reduce the laziness of the program; but this can always be
obviated, given sufficient care.
Using error-monad syntax might be a bit more palatable, but amounts to
essentially the same thing. Alternatively, you can define HOFs to
"lift" an n-ary function to an exception-propagating equivalent:
That is what I did with my Exception version 2 syntax.
The problem is that doing this lifting ends up being non-lazy.
You're right, it alters the strictness of the program. But one can
recover the original behaviour by delaying/eliminating the pattern-match,
though I again I agree this is a pain.
You could argue that this problem is an artifact of the Haskell syntax and
that we could add Exceptions to the Thunk to achieve the desired result
(treating exceptions as return values).
I don't think I would, though! (If I understand what you mean by this.)
The "problem" is an artifact of wanting to keep the language referentially
transparent, which a built-in throw/catch scheme of the sort you
suggest would scupper.
Our intuition is that foo' is commutative. foo' a b = foo' b a.
But that turns out not to be true when you have exceptions.
That's true. And it remains true _however_ one treats exceptions.
There's no way around that in general, I'm afraid, and I'll cite you
assorted papers on Observable Sequentiality if you really want the
grubby details.
But the real point here is that Exceptions are, by definition, results
that are outside the domain of the function being evaluated. Treating
exceptions as algebraic types may be comforting, but what you are really
doing in that case is extending the domain of your function
Effectively, yes. From a domain theory PoV, this is all that one could
possibly ever do, in fact ('error' included).
-- and there are limits to how far you can go with that.
These being?
Truly exceptional conditions are those that truly are outside of the
domain of the function being evaluated. e.g. factorial -1
The VALUE of (factorial -1) is not an exception. Neither is the value of
(factorial (1 `div` 0)).
When a function is passed bad arguments, it is not meaningful (from a
functional perspective) to have it return a value.
The value of a function over arguments outside its domain is undefined.
When such an event occurs, the logically consistent behavior is to exit
function evaluation and tell the caller what was wrong with the
arguments passed (to the extent it is possible to do).
I don't find this argument at all compelling. If a value is "truly
outside the domain of the function being evaluated", then don't pass
it to it! This may seem glib, but I do believe that its better SE
practice in general. If there are exceptional conditions in "the world",
or if determining a sufficient precondition is not practicable, then I
repeat my advice concerning exceptional return values, a necessary evil
though they might be.
Right now that means using the error function. I am just saying that
error isn't really enough for a production quality language.
Agreed.
Does this make more sense?
It makes perfect sense, but I think that having exceptions as a language
mechanism in Haskell is not realistic or viable, for the reasons I
outlined before. I don't pretend that the alternatives are trivial,
or even necessarily very pleasant-looking -- just that they're necessary.
Slainte,
Alex.
