configure problems
I'm trying to build a recent cvs checkout of glass.cse.ogi.edu:/cvs/fptools. First, I get the following error: checking for happy... /usr/bin/happy checking for version of happy... 1.14 configure: error: Happy version 1.15 or later is required to compile GHC. But the newest version of happy in Debian unstable is 1.14. Is 1.15 really required? Then when I change ./configure to only require 1.14 (since I'm just building documentation, I think maybe it isn't necessary) I see: checking for .subsections_via_symbols... configure: creating ./config.status config.status: creating mk/config.mk config.status: creating mk/config.h config.status: error: cannot find input file: mk/config.h.in I'm not sure if there was a problem with cvs, or what, but cvs up -dA mk/ doesn't help... Thanks, Frederik -- http://ofb.net/~frederik/ ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: configure problems
On 26 February 2005 03:25, Frederik Eaton wrote: I'm trying to build a recent cvs checkout of glass.cse.ogi.edu:/cvs/fptools. First, I get the following error: checking for happy... /usr/bin/happy checking for version of happy... 1.14 configure: error: Happy version 1.15 or later is required to compile GHC. But the newest version of happy in Debian unstable is 1.14. Is 1.15 really required? Yes, Happy 1.15 really is required. Then when I change ./configure to only require 1.14 (since I'm just building documentation, I think maybe it isn't necessary) I see: checking for .subsections_via_symbols... configure: creating ./config.status config.status: creating mk/config.mk config.status: creating mk/config.h config.status: error: cannot find input file: mk/config.h.in You should use 'autoreconf' rather than 'autoconf'. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1146068 ] Data.Generics type error
Bugs item #1146068, was opened at 2005-02-22 09:11
Message generated for change (Comment added) made by simonpj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1146068group_id=8032
Category: Compiler (Type checker)
Group: 6.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Data.Generics type error
Initial Comment:
I get a strange type error when using
Data.Generics.Twins - but if I include the text of the
definition in my own file it works!
I attach two files, one type checks, one does not. The
only difference is that I move a definition between
modules.
/Patrik
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2005-02-28 17:24
Message:
Logged In: YES
user_id=50165
Fixed, thank you. Type synonyms in interface files weren't
being hoisted. tc191.hs is the regression test
--
Comment By: Patrik Jansson (p1738j)
Date: 2005-02-22 12:10
Message:
Logged In: YES
user_id=1151788
Background: I tried to use Nils Ander Danielssons
ChasingBottoms package for doing some bottom-debugging
of code. In 6.2.2 it works fine, but when upgrading to a
6.4 release candidate I had to do this strange copying
--
Comment By: Patrik Jansson (p1738j)
Date: 2005-02-22 09:18
Message:
Logged In: YES
user_id=1151788
The error is the following:
Compiling Main ( testeq_bad.hs, interpreted )
testeq_bad.hs:21:34:
Inferred type is less polymorphic than expected
Quantified type variable `a' escapes
Expected type: a1 - GenericQ Bool
Inferred type: a1 - a - Bool
In the first argument of `gzipWithQ', namely `geq''
In the first argument of `and', namely `(gzipWithQ geq'
x y)'
Failed, modules loaded: none.
--
Comment By: Patrik Jansson (p1738j)
Date: 2005-02-22 09:16
Message:
Logged In: YES
user_id=1151788
-- I did not manage to later add the second file - here it
is instead:
-- I tested this with ghci-6.4.20050214
-
{-# OPTIONS -fglasgow-exts #-}
import Data.Generics.Basics
import Data.Generics.Aliases
import Data.Generics.Twins(gmapAccumQ)
-- | Twin map for queries
gzipWithQ :: GenericQ (GenericQ r) - GenericQ (GenericQ [r])
gzipWithQ f x y = case gmapAccumQ perkid funs y of
([], r) - r
_ - error gzipWithQ
where
perkid a d = (tail a, unGQ (head a) d)
funs = gmapQ (\k - GQ (f k)) x
-- | Generic equality: an alternative to \deriving Eq\
geq :: Data a = a - a - Bool
geq x y = geq' x y
where
geq' :: forall a b. (Data a, Data b) = a - b - Bool
geq' x y = (toConstr x == toConstr y)
and (gzipWithQ geq' x y)
--
Comment By: Patrik Jansson (p1738j)
Date: 2005-02-22 09:13
Message:
Logged In: YES
user_id=1151788
This was submitted by me (Patrik Jansson = p1738j at sf.net)
- I just loggon on too late.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1146068group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-1153674 ] option -cpp and having C comments gives wrong linenumbers
Bugs item #1153674, was opened at 2005-02-28 10:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1153674group_id=8032
Category: Compiler (Parser)
Group: 6.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: option -cpp and having C comments gives wrong linenumbers
Initial Comment:
If one tries to compile a .hs file, with the -cpp
option and the file contains
C-style comments (/* comment */), then the linenumbers
GHC reports
are wrong.
Minimal file exhibiting the error:
---
{-
/*
* Copyright (c) 2005 Jesper Louis Andersen
[EMAIL PROTECTED]
*
* Permission to use, copy, modify, and distribute this
software for any
* purpose with or without fee is hereby granted,
provided that the above
* copyright notice and this permission notice appear
in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR
DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
*/
-}
c = 3 * string
main = putStrLn $ show c
; ghc -cpp tmp.hs
tmp.hs:6:
No instance for (Num [Char])
arising from use of `*' at tmp.hs:6
In the definition of `c': c = 3 * string
Which is clearly wrong, since ``c'' is not defined on
line 6.
Note I am not sure wether it is in the parser, or it is
rather in compilation
chain where cpp gets invoked one has to look for the
error. I have filed
it as a parser-bug nonetheless.
Fix: cpp(1) seems to output comments in the style
# xx filename
where ``xx'' is a number stating the linenumber in the
original file.
Keeping track of this probably fixes the bug.
CPP version: GNU CPP from GCC 3.3.5
Operating System: OpenBSD 3.6-current (GENERIC) #1: Sun
Feb 20 10:23:54 CET 2005
Submitter: Jesper Louis Andersen [EMAIL PROTECTED]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1153674group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: 6.4.20050215: panic: lookupVers1 MHashTable HT{d}
On Mon, Feb 28, 2005 at 03:01:53AM -, Simon Peyton-Jones wrote: Ah, this one we fixed a few days ago. Works for me with the head. Thanks for your well-boiled-down bug reports; they are a lot faster to fix. Simon Thanks, it's nice to hear that. Though I consider it a fair deal: I'm spending more time on bug-boiling, and you're spending more time on the parts I still consider as being above my head ;) Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
Feature Requests item #1153029, was opened at 2005-02-27 12:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1153029group_id=8032 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1153029group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 6.2.2 x86_64 build failing
On 28 February 2005 05:38, Kip Macy wrote: In a clean tree I configured: ./configure --prefix=/u/kmacy/usr/x86_64 --with-ghc=/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64/ghc/compiler/ghc -inplace where the ghc-inplace is unregisterised, points to stage1, and is known to compile Hello World gcc -E -undef -traditional -P -I../includes-x c prelude/primops.txt.pp | \ grep -v '^#pragma GCC' prelude/primops.txt ../utils/genprimopcode/genprimopcode --data-decl prelude/primops.txt primop-data-decl.hs-incl /bin/sh: line 1: 14846 Segmentation fault (core dumped) ../utils/genprimopcode/genprimopcode --data-decl prelude/primops.txt primop-data-decl.hs-incl gmake[2]: *** [primop-data-decl.hs-incl] Error 139 gmake[2]: *** Deleting file `primop-data-decl.hs-incl' gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/u/kmacy/src/ghc/src/ghc-6.2.2-x86_64-x86_64-clean/ghc' gmake: *** [build] Error 1 It looks like genprimopcode is crashing. This is significant, because genprimopcode is the first Haskell program to be compiled and run by the compiler that you are bootstrapping with, so this indicates that even though your unregisterised stage1 is known to compile hello world, it still has some problems. Try adding -debug when compiling genprimopcode, and run it with gdb to get a backtrace. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[ ghc-Feature Requests-1153029 ] allow hierarchical module names with --make
Feature Requests item #1153029, was opened at 2005-02-27 20:24 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1153029group_id=8032 Category: None Group: None Status: Closed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: allow hierarchical module names with --make Initial Comment: It would be convenient (and consistent) to allow the use of hierarchical module names with --make, so that something like: ghc -isource_directory --make app.Main -o app would find the source_directory/app/Main.hs module to begin its processing. - Jeff Newbern [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2005-02-28 11:01 Message: Logged In: YES user_id=48280 You can use hierarchical module names with --make, but your module names must be a lexically correct; that is, each component must begin with an upper case letter. App.Main would work, app.Main is not a module name. More information on hierarchical modules here: http://www.haskell.org/hierarchical-modules/ and in the GHC User Guide. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=358032aid=1153029group_id=8032 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc HEAD and tee
On 25 February 2005 15:48, Christian Maeder wrote: we used redirect output of ghc via tee (within a Makefile). With the new ghc this randomly fails now. Does anyone have an explanation for this? ghc omitted args 21 | tee log yields: Skipping Main ( hets.hs, hets.o ) Linking ... tee: write error The linked binary and the log file are ok afterwards (and the mere size of the log is also no problem). Hmm, I can't reproduce this behaviour, and I can't imagine what the problem is: the error message claims a write error, so that would seem to indicate some kind of problem writing the log file, which can't be affected by GHC. Or perhaps that's just a generic error message from tee. Can you give any more details that might help us to reproduce it? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.4 release candidates available
Simon Peyton-Jones [EMAIL PROTECTED] writes: I think I've fixed this (on the head anyway; simon will merge to branch shortly). Care to try again? Yup, the toplevel rigid type-variable problem seems to have been fixed, thanks. nhc98 now builds as expected with ghc-6.4. BTW, there seems to be a small documentation-packaging fault in the linux binary distribution. You may be aware of it already. $ make install ... if test -d share/html; \ then cp -r share/html/* /usr/malcolm/local/share/ghc-6.4.20050227/html; \ fi for i in share/*.ps; do \ cp $i /usr/malcolm/local/share/ghc-6.4.20050227 ; \ done cp: cannot stat `share/*.ps': No such file or directory $ Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
segfault/massive memory use when using Data.Bits.shiftL
Hi, The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP. Prelude :m +Data.Bits Prelude Data.Bits 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
On Mon, Feb 28, 2005 at 02:55:56PM +, Ganesh Sittampalam wrote: Hi, The following either eats memory until killed or segfaults (I can't pin down a reason for the difference). Tested with GHC 6.2.2 and 6.4.20050212, with various different libgmp3s under various Redhat and Debian platforms, and WinXP. Prelude :m +Data.Bits Prelude Data.Bits 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer Cheers, Ganesh shiftL for Integer is defined in fptools/libraries/base/Data/Bits.hs: class Num a = Bits a where shiftL :: a - Int - a x `shiftL` i = x `shift` i instance Bits Integer where shift x i | i = 0= x * 2^i | otherwise = x `div` 2^(-i) IOW, for y 0: x `shiftL` y = x `shift` y = x `div` 2^(-y) and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :) Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge information.) Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
On Mon, 28 Feb 2005, Remi Turk wrote: On Mon, Feb 28, 2005 at 02:55:56PM +, Ganesh Sittampalam wrote: Prelude :m +Data.Bits Prelude Data.Bits 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :) Hmm, good point. I hadn't thought about the fact that the number of digits in the answer would be rather large... Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge information.) My googling suggests that gmp is prone to segfaulting when things get too large for it, so I'll just chalk it up to that. I apologise for thinking this was a bug :-) Cheers, Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: segfault/massive memory use when using Data.Bits.shiftL
On Mon, Feb 28, 2005 at 10:59:32PM +, Ganesh Sittampalam wrote: On Mon, 28 Feb 2005, Remi Turk wrote: On Mon, Feb 28, 2005 at 02:55:56PM +, Ganesh Sittampalam wrote: Prelude :m +Data.Bits Prelude Data.Bits 18446658724119492593 `shiftL` (-3586885994363551744) :: Integer and calculating, in your case, 2^3586885994363551744 is not something your computer is going to like... as it's probably a number which doesn't fit in our universe :) Hmm, good point. I hadn't thought about the fact that the number of digits in the answer would be rather large... Actually, the final answer will be 0: It's only the intermediate value that gets ridiculously large. Still, a segfault might point at a bug, which I unfortunately won't be able to say much about. (Due to lack of knowledge information.) My googling suggests that gmp is prone to segfaulting when things get too large for it, so I'll just chalk it up to that. I apologise for thinking this was a bug :-) No need to apologize. Segfaults _are_ IMHO almost always bugs. And in this case too, though the fault isn't GHCs. Groeten, Remi Cheers, Ganesh -- Nobody can be exactly like me. Even I have trouble doing it. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Scrap your boilerplate (but don't scrap them precious comments)
Hi,
I have been racking my brain over the infamous 'gfoldl' and 'gunfold'
combinators. (Yes, I have read the papers). What finally made me understand
how they worked was reading the code: first the implementation of the gmap
functions (Data/Generics/Basics.hs), then the long and detailed comments in
the same file, and finally the instance definitions for the built-in types
(in Data/Generics/Instances.hs).
IMHO, a lot of this could and should be part of the (haddock-generated)
documentation.
It is such a waste: all these wonderful comments in the source file, that
could be added to the docs with a keystroke! Instead, they simply say
Left-associative fold operation for constructor applications
which is really a bit terse for gfoldl, of which the source file comment
(rightly) states that its type is a headache.
Furthermore, (example) implementations can sometimes be extremely helpful to
understand things; this is especially true for a language like Haskell, in
which the implementation is often already the shortest (or at least a very
short) and most precise way to specify a functions semantics.
In this case, the implementations of gfoldl helped me to understand what the
function itself does. However, how and why these extremely abstract
combinators can serve as the basic building blocks of all the more concrete
and better understandable variants is best documented by the implementation
of just these variants gmapXX and friends. (Maybe one or two examples
implementations would suffice). At least, it should be stated in the docs
what the type constructor ('c') is in each case.
I don't know if haddock can add the implementation of a function to the
documentation. If not, such a feature should be considered.
SYB is a wonderful piece of work and deserves to be documented as well as it
is programmed.
Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Scrap your boilerplate (but don't scrap them precious comments)
That's a very good point.
Me too, I would often wish to see some principled
code details when entering documentation. For instance
what is the point of _explaining_ that inc aliases
add 1, why not just show that equation! I agree that
gmap?? are a bit of this kind. It is so much easier to
explain them, while showing code. It is so much of a
hassle to explain them while not showing code. The
implementations of gmap?? are almost like algebraic
properties ... I mean these are rather principled
implementations. A documentation tool should support
algebraic laws _and_ such principled implementations.
It would really help to link the function signatures
with the function definitions in the sense of a limited
code browsing functionality.
I am sure this is not a new discussion topic,
but we really need this IMHO.
Ralf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-
[EMAIL PROTECTED] On Behalf Of Benjamin Franksen
Sent: Monday, February 28, 2005 4:11 PM
To: glasgow-haskell-users@haskell.org
Subject: Scrap your boilerplate (but don't scrap them precious
comments)
Hi,
I have been racking my brain over the infamous 'gfoldl' and 'gunfold'
combinators. (Yes, I have read the papers). What finally made me
understand
how they worked was reading the code: first the implementation of the
gmap
functions (Data/Generics/Basics.hs), then the long and detailed
comments
in
the same file, and finally the instance definitions for the built-in
types
(in Data/Generics/Instances.hs).
IMHO, a lot of this could and should be part of the
(haddock-generated)
documentation.
It is such a waste: all these wonderful comments in the source file,
that
could be added to the docs with a keystroke! Instead, they simply say
Left-associative fold operation for constructor applications
which is really a bit terse for gfoldl, of which the source file
comment
(rightly) states that its type is a headache.
Furthermore, (example) implementations can sometimes be extremely
helpful
to
understand things; this is especially true for a language like
Haskell, in
which the implementation is often already the shortest (or at least a
very
short) and most precise way to specify a functions semantics.
In this case, the implementations of gfoldl helped me to understand
what
the
function itself does. However, how and why these extremely abstract
combinators can serve as the basic building blocks of all the more
concrete
and better understandable variants is best documented by the
implementation
of just these variants gmapXX and friends. (Maybe one or two examples
implementations would suffice). At least, it should be stated in the
docs
what the type constructor ('c') is in each case.
I don't know if haddock can add the implementation of a function to
the
documentation. If not, such a feature should be considered.
SYB is a wonderful piece of work and deserves to be documented as well
as
it
is programmed.
Ben
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Scrap your boilerplate (but don't scrap them precious comments)
On Mon, Feb 28, 2005 at 05:20:18PM -0800, Ralf Lammel wrote: That's a very good point. Me too, I would often wish to see some principled code details when entering documentation. For instance what is the point of _explaining_ that inc aliases add 1, why not just show that equation! I agree that gmap?? are a bit of this kind. It is so much easier to explain them, while showing code. It is so much of a hassle to explain them while not showing code. The implementations of gmap?? are almost like algebraic properties ... I mean these are rather principled implementations. A documentation tool should support algebraic laws _and_ such principled implementations. It would really help to link the function signatures with the function definitions in the sense of a limited code browsing functionality. I am sure this is not a new discussion topic, but we really need this IMHO. Yeah, I have wanted some special haddock identifier which means 'include the body of the function here'. Since often, this can be the best documentation. John -- John Meacham - repetae.netjohn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Type of y f = f . f
Is there a type we can give to y f = f . f y id y head y fst are all typeable? Jim Apple ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type of y f = f . f
On Mon, 28 Feb 2005 03:50:14 -0500 Jim Apple [EMAIL PROTECTED] wrote: Is there a type we can give to y f = f . f y id y head y fst are all typeable? Using ghci: Prelude let y f = f.f Prelude :t y y :: forall c. (c - c) - c - c So it admits principal type (a-a) - a-a. From this you can see that (y head) and (y fst) cannot be typed, whereas (y id) can. BTW, this function is usually named 'twice'. Best regards, Pedro -- Pedro Vasconcelos, School of Computer Science, University of St Andrews --- The difference between Theory and Practice is greater in Practice than in Theory. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type of y f = f . f
The name y suggests that you want to define the fixpoint combinator. This works as follows: Prelude let y f = f (y f) Prelude :type y y :: forall t. (t - t) - t Prelude y (\fac n - if n == 0 then 1 else n*fac(n-1)) 10 3628800 Prelude Till Pedro Vasconcelos wrote: On Mon, 28 Feb 2005 03:50:14 -0500 Jim Apple [EMAIL PROTECTED] wrote: Is there a type we can give to y f = f . f y id y head y fst are all typeable? Using ghci: Prelude let y f = f.f Prelude :t y y :: forall c. (c - c) - c - c So it admits principal type (a-a) - a-a. From this you can see that (y head) and (y fst) cannot be typed, whereas (y id) can. BTW, this function is usually named 'twice'. Best regards, Pedro -- Till Mossakowski Phone +49-421-218-4683 Dept. of Computer Science Fax +49-421-218-3054 University of Bremen [EMAIL PROTECTED] P.O.Box 330440, D-28334 Bremen http://www.tzi.de/~till ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Call for Tutorials - ICTAC05
Call for Tutorials - ICTAC05 INTERNATIONAL COLLOQUIUM ON THEORETICAL ASPECTS OF COMPUTING Hanoi, Vietnam - 17--21 October, 2005 http://www.iist.unu.edu/ictac05 = BACKGROUND AND OBJECTIVES ICTAC is an International Colloquium on Theoretical Aspects of Computing founded by the International Institute for Software Technology of the United Nations University (UNU-IIST). The aim of the colloquium is to bring together practitioners and researchers from academia, industry and government to present research results, and exchange experience, ideas, and solutions for their problems in theoretical aspects of computing.The colloquium is aimed particularly, but not exclusively, at participants from developing countries. We believe that this will help developing countries to strengthen their research, teaching and development in computer science and engineering, improve the links between developing countries and developed countries, and establish collaboration in research and education. The first ICTAC (ICTAC'04) was held in Guiyang, China and its proceedings were published as ICTAC 2004: Theoretical Aspects of Computing, LNCS 3407. ICTAC'05 will have a technical program for five days including two days for tutorials and three days for a conference, and a training school for 5 days. The topics of the conference include, but are not limited to: - automata theory and formal languages - principles and semantics of programming languages - logics and their applications - software architectures and their description languages - software specification, refinement, and verification - model checking and theorem proving - formal techniques in software testing - models of object and component systems - coordination and feature interaction - integration of formal and engineering methods - service-oriented development - document-driven development - models of concurrency, security, and mobility - theory of parallel, distributed, and internet-based (grid) computing - real-time and embedded systems - type and category theory in computer science SPONSORS AND ORGANISATION ICTAC'05 will be organised jointly between the Institute of Information Technology of the Vietnamese Academy of Sciences and Technology (IoIT), the University of Technology of the Vietnam National University in Hanoi (UoT-VNU) and UNU-IIST. UNU-IIST, IoIT and UoT-VNU are also sponsors of ICTAC'05. There will be an one-week training school during 10--14 October 2005 before the conference. TUTORIAL SUBMISSION You are welcome to submit a proposal for a tutorial on any subject related to the topics listed above. All tutorial proposal submissions should have a detailed description of the tutorial contents, the time duration, and an extended abstract written in English. The extended abstract should not not exceed 5 pages in LNCS format (see http://www.springer.de/comp/lncs/authors.html for details). The extended abstract of the accepted tutorials will be published in the proceedings of the ICTAC05 conference which will be published by Springer in the Lecture Notes in Computer Science series. All queries and tutorial proposals should be sent to the program committee co-chairs Dang Van Hung, e-mail: [EMAIL PROTECTED], or Martin Wirsing, e-mail: [EMAIL PROTECTED] The deadline for tutorial proposal submission is 11 July 2005, and the notification of tutorial proposal acceptance is 25 July 2005. The date for tutorials is 17-18 October, 2005. ADVISORY COMMITTEE Dines Bjorner, Singapore Manfred Broy, Germany Jifeng He, UNU-IIST Mathai Joseph, India Shaoying Liu, Japan Zhiming Liu, UNU-IIST Jim Woodcock, UK Jose Luiz Fiadeiro, UK Tobias Nipkow, Germany PUBLICITY CHAIR Bernhard K. Aichernig, UNU-IIST ORGANISING COMMITTEE Le Hai Khoi, IoIT (co-chair) Ho Si Dam, UoT-VNU (co-chair) Nguyen Tue, UoT-VNU Bui The Duy, UoT-VNU Nguyen Viet Ha, UoT-VNU Vu Duc Thi, IoIT Le Quoc Hung, IoIT Do Nang Toan, IoIT Ngo Quoc Tao, IoIT PROGRAM COMMITTEE Marc Aiguier, France Keijiro Araki, Japan J.O.A. Ayeni, Nigeria Jay Bagga, USA Hubert Baumeister, Germany Michel Bidoit, France Jonathan Bowen, UK Victor A. Braberman, Argentina Cristian S. Calude, New Zealand Ana Cavalcanti, UK Yifeng Chen, UK Dang Van Hung, UNU-IIST (co-chair) Jim Davies, UK Janos Demetrovics, Hungary Jin Song Dong, Singapore Henning Dierks, Germany Do Long Van, Vietnam Marcelo F. Frias, Argentina Wan Fokkink, Netherlands Susanna Graf, France Valentin Goranko, South Africa Dimitar Guelev, Bulgaria Michael R. Hansen, Denmark Jozef Hooman, Netherlands Purush Iyer, USA Ryszard Janicki, Canada Takuya Katayama, Japan Maciej Koutny, UK Xuandong Li, China Antonia Lopes, Portugal Antoni Mazurkiewicz, Poland Hrushikesha Mohanty, India Ngo Quang Hung, USA Nguyen Cat Ho, Vietnam Paritosh Pandya, India Jean-Eric Pin, France Narjes Ben Rajeb, Tunisia R. Ramanujam, India. Anders P. Ravn, Denmark Gianna Reggio, Italy Wolfgang Reif, Germany Riadh Robbana, Tunisia Mark Ryan, UK Zaidi Sahnoun, Algeria Augusto Sampaio, Brazil
[Haskell] postgresql foreign function call segfaults
Hi Group, i'm trying to complete an haskell pgsql interface. all compiles well when using ghc's generated executable but it segfaults when i do a pqexec. -- PGresult *PQexec(PGconn *conn, const char *query); foreign import ccall libpq-fe.h PQexec pqexec::X_PGconn-CString-IO X_PGresult here's the offending code: create conn=do putStrLn creating table products putStrLn (\t++screate) q- newCString screate -- segmentation fault here! rs- pqexec conn q stat- pqcmdstatus rs stats-peekCString stat putStrLn (\tstatus is: ++ show stats) ra- pqcmdtuples rs ras-peekCString ra putStrLn (\trows affected is: ++ show ras) screate= CREATE TABLE products ( ++ product_no integer, ++ name text, ++ price numeric ++) i'm using pgsql 7.4, gcc 3.3.4, ghc 6.2.2 i tried compiling with -fvia-C and it doesn't finish compiling. i'm asking this question in the fear that i have done something wrong. i have posted my code the code, makefile and generated .hc file here: http://www.eyan.org/haskell/ -- kind regards, eyan http://www.eyan.org ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type of y f = f . f
Pedro Vasconcelos wrote: Jim Apple [EMAIL PROTECTED] wrote: Is there a type we can give to y f = f . f y id y head y fst are all typeable? Using ghci: Prelude let y f = f.f Prelude :t y y :: forall c. (c - c) - c - c So it admits principal type (a-a) - a-a. From this you can see that (y head) and (y fst) cannot be typed, whereas (y id) can. I think the OP's point is that all three of his examples make sense, and the resulting functions would have Haskell types, yet there doesn't seem to be a Haskell type which permits all three uses of y. I can come up with types which permit any one of the three: y :: forall a. (a - a) - a - a y :: forall a f. (forall x. f x - x) - f (f a) - a y :: forall a b c f. (forall x y. f x y - x) - f (f a b) c - a but I can't find a type which permits more than one. It can probably be done with type classes. -- Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Building a dynamic loadable Parsec parser
Hi, I've got a little parser written using Parsec that I want to link into some C code. I start by compiling the Haskell sources like so: ghc -ffi -fglasgow-exts -main-is My_Init -c parse.hs When linking parse.o and parse_stub.o against my (additional) glue code, I get the following errors: Main.o(.text+0xc): undefined reference to `__stginit_ZCMain' Main.o(.text+0x14): undefined reference to `__stginit_ZCMain' Main.o(.text+0x20): undefined reference to `ZCMain_main_closure' Main.o(.text+0x24): undefined reference to `ZCMain_main_closure' I'm trying to build a .so that I can load into another process (via Tcl, actually). If I define a main function in my C glue code, these errors go away. But I can't have a main function in this .so. So, two questions: - is it possible to compile and link these .o files into a .so (on Solaris, using ghc 6.2.2)? - what do I need to do to create an entry point for this Haskell code that _isn't_ called main()? Thanks, -- Adam ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type of y f = f . f
On 2005-02-28 at 18:03GMT Ben Rudiak-Gould wrote: Pedro Vasconcelos wrote: Jim Apple [EMAIL PROTECTED] wrote: Is there a type we can give to y f = f . f y id y head y fst are all typeable? Using ghci: Prelude let y f = f.f Prelude :t y y :: forall c. (c - c) - c - c So it admits principal type (a-a) - a-a. From this you can see that (y head) and (y fst) cannot be typed, whereas (y id) can. I think the OP's point is that all three of his examples make sense, and the resulting functions would have Haskell types, yet there doesn't seem to be a Haskell type which permits all three uses of y. The problem is that the type system needs to be checkable, so has to throw some information away. if y f = f . f, the easiest way of losing information is to require that the output type of f be the same as the input. It certainly needs to be a type acceptable as input to f. if you put th f = f . f . f the examples still make sense, but should the type of th be different from the type of y? but I can't find a type which permits more than one. Not in Haskell. If you allow quantification over higher kinds, you can do something like this: d f = f . f d:: a::*, b::**.(b a a) b (b a) a Now we can type d id id :: t . t t so id :: t . (t.t) t t ie b is (t.t) so d id :: (t.t)((t.t) t) t :: t . t t and d head head:: t.[t]t so b is [] so d head :: t . [[t]] t and fst :: x,y.(x,y)x so b is x.(x,y) d fst :: t,y . (x.(x,y))((x.(x,y)) t) t :: t,y . (x.(x,y))(t,y) t :: t,y . ((t,y),y) t (oops, only one y) but you would be expecting a bit much of a compiler to infer any of this. -- Jn Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Building a dynamic loadable Parsec parser
adam.turoff: Hi, I've got a little parser written using Parsec that I want to link into some C code. I start by compiling the Haskell sources like so: ghc -ffi -fglasgow-exts -main-is My_Init -c parse.hs When linking parse.o and parse_stub.o against my (additional) glue code, I get the following errors: Main.o(.text+0xc): undefined reference to `__stginit_ZCMain' Main.o(.text+0x14): undefined reference to `__stginit_ZCMain' Main.o(.text+0x20): undefined reference to `ZCMain_main_closure' Main.o(.text+0x24): undefined reference to `ZCMain_main_closure' I'm trying to build a .so that I can load into another process (via Tcl, actually). If I define a main function in my C glue code, these errors go away. But I can't have a main function in this .so. So, two questions: - is it possible to compile and link these .o files into a .so (on Solaris, using ghc 6.2.2)? - what do I need to do to create an entry point for this Haskell code that _isn't_ called main()? I think that unless you use the -PIC stuff that Wolfgang committed recently then you'll have to instead use hs-plugins to do the dynamic loading on the Haskell side. I'm fairly certain the pic stuff won't work on Solaris. Essentially, you write a Haskell wrapper module over the parser that calls hs-plugins to load your parser. Then, using the FFI, expose a hook to this wrapper module, and call that from C. There's an example doing this from Objective C in the hs-plugins paper. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow \= for field update in record update syntax
On Thursday 24 February 2005 23:27, Keean Schupke wrote: Benjamin Franksen wrote: Well at the moment this would give an error, but remember the list is heterogeneous, so you can just not give the list a type, and simply append the specific function... admitedly this is not as type-safe. hUpdateAtLabel field2 someFunction myRecord That is an advantage of hLists as compared to normal records. A disadvantage is that each field access needs to traverse the list. I wonder if this isn't rather less efficient than the random access provided by normal records. Well, not quite true, because the type of the label is used to index the value, the selection happens at compile time. So at run time there is no instance selection left... it is simply the value. At least in theory! whether the particular compiler/interpreter does this is implementation dependant. This is why we decided that the simpler to implement list was better than a more complex tree structure. Hmm. I haven't seen it from this perspective, yet! At first reading, I thought this is simply too good to be true. I mean, there is some sort of list structured thing representing the whole record, right? Then how can the function that selects an element *not* traverse through the list? After thinking for some time about this, my head begins to spin badly! I tend to believe now, that it could indeed be possible that the compiler performs the traversal at compile time, but the thought still gives me headaches. Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Type of y f = f . f
Jon Fairbairn writes: On 2005-02-28 at 18:03GMT Ben Rudiak-Gould wrote: Pedro Vasconcelos wrote: Jim Apple [EMAIL PROTECTED] wrote: Is there a type we can give to y f = f . f y id y head y fst are all typeable? Using ghci: Prelude let y f = f.f Prelude :t y y :: forall c. (c - c) - c - c So it admits principal type (a-a) - a-a. From this you can see that (y head) and (y fst) cannot be typed, whereas (y id) can. I think the OP's point is that all three of his examples make sense, and the resulting functions would have Haskell types, yet there doesn't seem to be a Haskell type which permits all three uses of y. The problem is that the type system needs to be checkable, so has to throw some information away. There are type systems which can type this, but they have their own quirks. For example, System E [1] would give us: y :: (a - b b - c) - a - c where a b is the intersection of types a and b. The advantage of System E over, say, System F, is that type inferencing is decidable. The downside is that the inferred types can be pretty long. [1] http://www.macs.hw.ac.uk/~sebc/ -- David Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Type of y f = f . f
Jon Fairbairn wrote: If you allow quantification over higher kinds, you can do something like this: d f = f . f d:: a::*, b::**.(b a a) b (b a) a What's the problem with d :: (forall c . b c - c) - b (b a) - a d f = f . f to which ghci gives the type d :: forall a b. (forall c. b c - c) - b (b a) - a Jim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell-cafe] how to avoid overlapping instance error?
If you are not using them to prevent overlapping instances, then why require instance decls at all? For example, why does GHC require an instance decl here: instance (Ord x)=ToSet [] x where toSet = Set.fromList But not here: listToSet x = Set.fromList x Or I suppose, one could rephrase this question as why not simplify instance declarations to be: instance ToSet where toSet = Set.fromList And let the typechecker take care of figuring out what instance is being specified here? -Alex- __ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Mon, 28 Feb 2005, Simon Peyton-Jones wrote: Unfortunately, the context of an instance decl is not taken into account when matching instance decls. Yes, it would make sense to do so, but it'd make the system yet more complicated. So Show (table item) overlaps with Show ([] item) Overlap is checked lazily, so if you look for Show (MyTable t) you won't get overlap. Only if you ask for Show (table item), where the type checker still doesn't know what type 'table' is going to be, do you get a problem. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of S. | Alexander Jacobson | Sent: 25 February 2005 17:09 | To: haskell-cafe@haskell.org | Subject: [Haskell-cafe] how to avoid overlapping instance error? | | | Currently, the HAppS.DBMS lib requires the user to provide a Show | instance for their table types. An example might be: | | instance (Show item) = Show (MyTable item) where | showsPrec d table = showsPrec d $ Set.toList $ myTableSet table | | But the Table class itself defines a toSet function so I think I | should be able to do this once for all Table instances: | | instance (Show item,Ord item, Table table item p) = Show (table item) where | showsPrec d table = showsPrec d $ Set.toList $ toSet table | | But I get an error telling me I am overlapping with Show [a]. | | Since [] is not an instance of Table, I don't see why there should be | an overlap. | | -Alex- | | __ | S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Numeric vs. relative precedences of infix operators
Is it widely accepted that the precedence of infix operators is defined by numbers? The numbers look arbitrary to me and it is not possible to introduce infix operators with interim precedences. What about defining relations such as (*) has precedence over (+)? The compiler could construct a topographically ordered graph from these relations. This way it would also be possible that from two infix operators none has precedence over the other (although the have not the _same_ precedence), thus the sub-expressions with these operators must be enclosed in parentheses. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numeric vs. relative precedences of infix operators
Henning Thielemann writes: Is it widely accepted that the precedence of infix operators is defined by numbers? The numbers look arbitrary to me and it is not possible to introduce infix operators with interim precedences. What about defining relations such as (*) has precedence over (+)? The compiler could construct a topographically ordered graph from these relations. Widely accepted is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc. Why not 10, 20, 30,... ?? When I taught compilation, I suggested to use pairs (lprec,rprec) to denote simultaneously the precedence and the associativity. The parsing becomes quite homogeneous. (This is a very old idea, not mine, obviously...) Of course, there is a necessity to define the non-associativity as well... Some partial ordering is needed. But in this style it is even possible to declare bracketing operators. If the lprec of the second is equal to lprec of the first, then *both* operators are reduced. Parentheses become operators as all others... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] postgresql foreign function call segfaults
Hi Group, i'm trying to complete an haskell pgsql interface. all compiles well when using ghc's generated executable but it segfaults when i do a pqexec. -- PGresult *PQexec(PGconn *conn, const char *query); foreign import ccall libpq-fe.h PQexec pqexec::X_PGconn-CString-IO X_PGresult here's the offending code: create conn=do putStrLn creating table products putStrLn (\t++screate) q- newCString screate -- segmentation fault here! rs- pqexec conn q stat- pqcmdstatus rs stats-peekCString stat putStrLn (\tstatus is: ++ show stats) ra- pqcmdtuples rs ras-peekCString ra putStrLn (\trows affected is: ++ show ras) screate= CREATE TABLE products ( ++ product_no integer, ++ name text, ++ price numeric ++) i'm using pgsql 7.4, gcc 3.3.4, ghc 6.2.2 i tried compiling with -fvia-C and it doesn't finish compiling. i'm asking this question in the fear that i have done something wrong. i have posted my code here: http://www.eyan.org/haskell/Postgresql.hsc the makefile i'm using is here: http://www.eyan.org/haskell/Makefile the generated hc file is here: http://www.eyan.org/haskell/POstgresql.hc -- kind regards, eyan http://www.eyan.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Bound threads
Simon Marlow [EMAIL PROTECTED] writes: Is it important which thread executes Haskell code (I bet no) and unsafe foreign calls (I don't know)? If not, couldn't the same OS thread execute code of both threads until a safe foreign call is made? Actually in a bound thread, *all* foreign calls must be made using the correct OS thread, not just the safe ones. So your scheme would involve a context switch at every foreign call, which would end up being rather expensive. Ok. As I understand this (and as I'm trying to implement a similar scheme for my language), when an unbound thread performs a safe C call, the current OS thread transforms from a worker to a bound thread, and another worker is spawn if needed for remaining Haskell threads. So I have another idea: Why is the main thread bound? Wouldn't it be sufficient that, in cases where it's important to have the main Haskell thread bound to the main OS thread, the programmer wraps the main computation in a function which calls C and then calls back Haskell? Such function, if executed before spawning other threads which perform safe C calls, would in effect bind the threads together. That way there would be no OS thread synchronization needed when the main Haskell thread synchronizes with unbound threads. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] how to avoid overlapping instance error?
| Or I suppose, one could rephrase this question as why not | simplify instance declarations to be: | |instance ToSet where | toSet = Set.fromList | | And let the typechecker take care of figuring out what instance is | being specified here? That might be possible, but Haskell forces you to be a bit more explicit, that's all. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Browser-like UI
Hi, I've seen some options for GUI programming in Haskell libraries page, but what I really would like is to define my user interface using HTML (or, maybe, SVG). What are the options to do that in Haskell? I've read that Gtk2Hs has a mozilla rendering engine, but unfortunatly that won't build on my 64Mb computer. What else can I use? How does that work, can I handle HTML events with Haskell code? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Numeric vs. relative precedences of infix operators
G'day all. Quoting [EMAIL PROTECTED]: Widely accepted is a widely accepted relativism... I am also annoyed by the precedences 0,1,2, ...,9, etc. Why not 10, 20, 30,... ?? I _think_ we had this back around Haskell 1.1 (which I never used, but early Gofers also had it). Moreover, operators could also have arbitrary fixity (prefix, infix, postfix). I'm not sure why this feature was dropped, but it's probably to do with the fact that when you do this, the language no longer has a managable LR grammar. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
