[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex
Bugs item #802692, was opened at 2003-09-08 19:40
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
Category: hslibs/text
Group: 6.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Remi Turk (remit)
Assigned to: Simon Marlow (simonmar)
Summary: SIGSEGV in Text.Regex
Initial Comment:
Hi all,
while writing a little download-some-weblog-program I
encountered what appears to be a memory management
bug in Text.Regex of ghc-6.0.1.
Both 6.0 and 6.0.1 crash. I didn't try other versions yet.
possible interesting information can be found at:
http://home.wanadoo.nl/remi.turk/tmp/LJGet/core.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.hs
If I need to provide additional information or isolate
the problem into a smaller code-fragment, please let me
know.
Happy hacking,
Remi
some gdb-info:
{- gdb copyright info... -}
Program terminated with signal 11, Segmentation fault.
{- reading symbols from... -}
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) info stack
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
#1 0x400f883e in __libc_free (mem=0x4045cc00) at
malloc.c:3023
#2 0x40132fd2 in __regfree (preg=0x40205058) at
regex.c:5866
#3 0x805720f in s686_info ()
#4 0x805a4f0 in s4zy_ret ()
#5 0x4c58308 in ?? ()
Cannot access memory at address 0x99548be
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-10 11:53
Message:
Logged In: YES
user_id=48280
Yes, it is indeed a separate bug. I've just fixed it in the
HEAD, but I'm afraid there isn't a workaround for 6.0.1.
Text.Regex is sadly broken, *sigh*.
The URLs in the bug report were unreadable from here because
our proxy is blocking that site, for some unknown reason.
--
Comment By: Remi Turk (remit)
Date: 2003-09-09 21:36
Message:
Logged In: YES
user_id=26642
*verifying*
yes it does crash with 6.0.1.
I can reach the files without any problem, both from home
and from university. Are they still unreachable?
--
Comment By: Hampus Ram (hampusr)
Date: 2003-09-09 19:47
Message:
Logged In: YES
user_id=159064
I too get a sigsegv when I run the given code (the links
work just fine for me) and I've tried with both ghc 6.0.1
and CVS version from about a week ago.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-09 08:58
Message:
Logged In: YES
user_id=48280
Strange - I thought I fixed this bug between 6.0 and 6.0.1.
You're absolutely certain it happens with 6.0.1?
The URLs in your bug report don't work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Weird Undecidable Instances Bug
original, g is actually a method in a class, and its definition is in
an instance declaration. Its type is actually given, not annotated. For
instance:
Ah, g is meant to be a method. Well, ...
-- ghc -fglasgow-exts -fallow-undecidable-instances -c WeirdInsts.hs
module WeirdInsts where
{
data T r = MkT;
class C t;
class D b t;
instance (C (T r)) = D b (T r); -- (1)
class F a b | a - b;
f :: (F a b,D b t) = (a,t);
f = undefined;
class G t where
{
g :: forall a b. (F a b,D b t) = (a,t);
};
instance G (T r) where
{
g = f;
};
}
This exhibits the same behaviour.
... not quite. Cause we never can improve class declarations.
The short answer is, the above code won't type check in
a compilation-based evidence translation scheme.
(There are no issues with decidable inference etc.)
Reason:
g's method declaration (i.e. annotation) is too general.
When type checking the instance, we need to check for
(F a' b',D b' t') = (a',t')
subsumes
(F a b,D b (T r)) = (a,t)
(foralls are implicit)
In a compilation-based evidence translation scheme this check fails.
(BTW, there were similar problems mentioned when trying to define Monad2
instances some time ago on Haskell mail).
There are two solutions:
(1)
In an interpreter-based evidence translation scheme this
check would succeed. (i.e. we only
construct evidence at run-time, though this requires to pass around
run-time type information, see A Theory of Overloading, journal
version, for details
http://www.comp.nus.edu.sg/~sulzmann/chr/publications.html)
(2)
We need to find a different encoding. In essence, we need to give
up the class declaration.
That is, we first generate
class G a where g :: a
instance (F a b, D b (T r)) = G (a, T r) where
g = f
however, this won't work either, same problem as before.
Additionally, we need to improve
the instance (an instance is nothing else than a type annotation).
Finally, the following works
class G a where g :: a
instance (F a b, C (T r)) = G (a, T r) where
g = f
Martin
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-792761 ] rts_getBool: not a Bool
Bugs item #792761, was opened at 2003-08-21 20:46 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=792761group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: rts_getBool: not a Bool Initial Comment: On ghc 5.04.1 on redhat 7.x I have a C program which calls Haskell thorugh the FFI. It compiles and runs correctly. However on ghc 5.04.3 with Mandrake 9.0 (ie gcc 3.2) the same program fails with main: fatal error: rts_getBool: not a Bool All my functions return Bool to signify failure or success. If I replace them by Int, then the program works again on Mandrake. To contact me, sengan `dot` baring-gould `at` ia `period` nsc `full-stop` com -- Comment By: Simon Marlow (simonmar) Date: 2003-09-10 14:34 Message: Logged In: YES user_id=48280 Can you provide us with some code that reproduces the problem? -- Comment By: Nobody/Anonymous (nobody) Date: 2003-08-28 17:01 Message: Logged In: NO I'm running ghc. FWIW my email address changed to amd `dot` com -- Comment By: Simon Marlow (simonmar) Date: 2003-08-26 12:07 Message: Logged In: YES user_id=48280 Are you running the program in GHCi, or plan GHC? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=792761group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Segmentation fault with GHCi 6.0
Oh dear. This is a new one on me: Prelude Control.Exception.throwDyn (1::Int) segmentation fault Now fixed in the HEAD. Cheers, Simon ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex
Bugs item #802692, was opened at 2003-09-08 21:40
Message generated for change (Comment added) made by remit
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
Category: hslibs/text
Group: 6.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Remi Turk (remit)
Assigned to: Simon Marlow (simonmar)
Summary: SIGSEGV in Text.Regex
Initial Comment:
Hi all,
while writing a little download-some-weblog-program I
encountered what appears to be a memory management
bug in Text.Regex of ghc-6.0.1.
Both 6.0 and 6.0.1 crash. I didn't try other versions yet.
possible interesting information can be found at:
http://home.wanadoo.nl/remi.turk/tmp/LJGet/core.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.bz2
http://home.wanadoo.nl/remi.turk/tmp/LJGet/grepHref.hs
If I need to provide additional information or isolate
the problem into a smaller code-fragment, please let me
know.
Happy hacking,
Remi
some gdb-info:
{- gdb copyright info... -}
Program terminated with signal 11, Segmentation fault.
{- reading symbols from... -}
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
3049malloc.c: No such file or directory.
(gdb) info stack
#0 chunk_free (ar_ptr=0x0, p=0x4045cbf8) at malloc.c:3049
#1 0x400f883e in __libc_free (mem=0x4045cc00) at
malloc.c:3023
#2 0x40132fd2 in __regfree (preg=0x40205058) at
regex.c:5866
#3 0x805720f in s686_info ()
#4 0x805a4f0 in s4zy_ret ()
#5 0x4c58308 in ?? ()
Cannot access memory at address 0x99548be
--
Comment By: Remi Turk (remit)
Date: 2003-09-10 22:23
Message:
Logged In: YES
user_id=26642
thanks, I'll take a look at GHC-CVS soon I guess :)
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-10 13:53
Message:
Logged In: YES
user_id=48280
Yes, it is indeed a separate bug. I've just fixed it in the
HEAD, but I'm afraid there isn't a workaround for 6.0.1.
Text.Regex is sadly broken, *sigh*.
The URLs in the bug report were unreadable from here because
our proxy is blocking that site, for some unknown reason.
--
Comment By: Remi Turk (remit)
Date: 2003-09-09 23:36
Message:
Logged In: YES
user_id=26642
*verifying*
yes it does crash with 6.0.1.
I can reach the files without any problem, both from home
and from university. Are they still unreachable?
--
Comment By: Hampus Ram (hampusr)
Date: 2003-09-09 21:47
Message:
Logged In: YES
user_id=159064
I too get a sigsegv when I run the given code (the links
work just fine for me) and I've tried with both ghc 6.0.1
and CVS version from about a week ago.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-09 10:58
Message:
Logged In: YES
user_id=48280
Strange - I thought I fixed this bug between 6.0 and 6.0.1.
You're absolutely certain it happens with 6.0.1?
The URLs in your bug report don't work.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-759910 ] Non-exhaultive patterns from derived Read
Bugs item #759910, was opened at 2003-06-24 09:14 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=759910group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Non-exhaultive patterns from derived Read Initial Comment: When switching from GHC 5.04.1 to 6.0 I started getting a load of warnings like these: source/SDL/Types.hs:33: Warning: Pattern match(es) are non-exhaustive In a pattern binding in a 'do' expression: Patterns not matched: Text.Read.Lex.EOF Text.Read.Lex.Rat _ Text.Read.Lex.Int _ Text.Read.Lex.Symbol _ ... The source in question looks like this data Expected = ExpectedType String | ExpectedValue String deriving (Read, Show) It looks as though everything deriving Read causes this warning (there are several such constructs in the file). Deriving only Show does not. Found no mention of change to behavior of derived reads in release notes or in google. Cheers, Jason Feingold [EMAIL PROTECTED] -- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-10 14:09 Message: Logged In: NO You are correct, -fwarn-simple-patterns is enabled. -- Comment By: Simon Peyton Jones (simonpj) Date: 2003-06-25 01:16 Message: Logged In: YES user_id=50165 You must be using -fwarn-simple-patterns too, right? You're right that the error message is misleading, but it's not particularly easy to fix, so I've settled for improving the documentation of that flag. -- Comment By: Nobody/Anonymous (nobody) Date: 2003-06-24 09:16 Message: Logged In: NO BTW, I'm running on Windows 2000. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=759910group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: stg_ap_v_ret porting crash: solved?
$ uname -msr OpenBSD 3.3 sparc $ cat test.hs import System.Info main = print System.Info.arch print System.Info.os $ /usr/obj/ports/ghc-6.0.1/ghc-6.0.1/ghc/compiler/ghc-inplace test.hs $ ./a.out sparc openbsd Congrats :-) Would you like to add this port to the relevant section of the Building Guide? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Wed, Sep 10, 2003 at 08:31:40AM +1000, Donald Bruce Stewart wrote: Following the new guide, and the new distrib/hc-build, with the fix to .hc file generation on the host that Simon sorted out yesterday. This generated a working sparc binary. That compiler in turn is recompiling the libraries and generating new .hi files. Looks like it's working here too :-) Bootstrapping IA64 from x86 (with numerous patches from CVS) looks like it is working fine, although I am getting ghc-6.0.1(9371): unaligned access to 0x41e6177a, ip=0x40dd46c1 when compiling even hello world with optimisation. The result seems to work fine though. Is this expected? Or maybe I missed a patch? [Added Matt Chapman to the CC list] Things aren't so easy with alpha as gcc rejects the -mieee flag when GHC calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order. Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
igloo: On Wed, Sep 10, 2003 at 08:31:40AM +1000, Donald Bruce Stewart wrote: Following the new guide, and the new distrib/hc-build, with the fix to .hc file generation on the host that Simon sorted out yesterday. This generated a working sparc binary. That compiler in turn is recompiling the libraries and generating new .hi files. Looks like it's working here too :-) The sparc isn't entirely well-behaved. The unregisterised compiler seems fine, but the first go at building a registerised GHC built a stage1 compiler that couldn't allocate memory. However, I was being ambitious and had turned on everything: nativeGen, ghci, regs, tail calls etc. I'm being more cautious second time around. I'm having a go at alpha (osf3) too, I'll let you know. As an aside: I'll post bin-dists when registersied builds work. -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Thu, Sep 11, 2003 at 02:06:57AM +0100, Ian Lynagh wrote: Bootstrapping IA64 from x86 (with numerous patches from CVS) looks like it is working fine, although I am getting ghc-6.0.1(9371): unaligned access to 0x41e6177a, ip=0x40dd46c1 when compiling even hello world with optimisation. The result seems to work fine though. Is this expected? Or maybe I missed a patch? Hmm, no, I don't get any unaligned accesses. My tree is a few months old though, I will update and check. Matt ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The Future of Haskell discussion at the Haskell Workshop
On Wednesday 10 September 2003 04:54, Andrew J Bromage wrote: G'day all. On Tue, Sep 09, 2003 at 02:52:48PM +0200, Johannes Waldmann wrote: but this might be an issue for others, who have to maintain legacy code. You know a language has made it when we're talking about legacy code. On the other hand, you have to worry about a pure declarative language where support for anything legacy is a priority. Just a little bit. On reflection, I can think of one group of Haskellers who might get a bit upset by such changes. If I'd written (or purchased) a text book which was now full of obsoleted code examples I wouldn't be very happy. But I guess it would be possible to do something too suit users of old and new Haskell with suitably chosen pragmas or compiler switches without too much difficulty. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Iavor Diatchki [EMAIL PROTECTED] writes: Adrian Hey wrote: IMHO preserving the status quo wrt records should be low priority. It really doesn't bother me much if new (useful) language features break existing code. I think this is a better option than permanently impoverishing the language and/or forcing users to migrate their entire code to some other less impoverished language which may appear in the future. I also think that having backwards compatability is not much of an issue. After all, ghc has introduces a number of not backward compatable changes to haskell, and I never heard any complaints. Oh no? Implicit parameters: I'm sure it is a great thing, but I'd already used the (?) operator, and need -fglasgow-exts. Now my program depends on a bunch of well places spaces to compile. Template Haskell: really cool new feature, which just happens to use a syntax that overlaps with the list comprehension syntax. And now, let's just screw any backwards compatibility, and re-engineer the records system¹. I don't need any of this, and it makes my life harder. Are you guys going to keep at it, until I regret ever using Haskell? There was recently a thread about using Haskell for something else than Haskell compilers; well, if you actually want people to do this, then you can't constantly keep changing the language. -kzm PS: For the record, I think the compiler developers are in general doing a great job of augmenting the language *without sacrificing backwards compatibility*. But compatibility is important. Branch GHC and develop a new language instead! -- 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: The Future of Haskell discussion at the Haskell Workshop
What about ad-hoc overloading (allowing visible entities to share names, as long as they can be distinugished by their typing). This is orthogonal to the proper records issue (?) but it might improve the current situtation (?) and it seems backward-compatible (?) Of course this would need an extension of the type checker (but not in the interface files, since this kind of overloading should only happen when using an name, not when defining it). -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/209 -- .. .. Viertes Leipziger Jongliertreffen, 17. - 19. Oktober 2003 .. .. .. .. http://www.informatik.uni-leipzig.de/~joe/juggling/vier/ .. .. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Johannes Waldmann [EMAIL PROTECTED] writes: What about ad-hoc overloading (allowing visible entities to share names, as long as they can be distinugished by their typing). This is orthogonal to the proper records issue (?) but it might improve the current situtation (?) and it seems backward-compatible (?) Yes. Don't get me wrong; please go and define proper records, improve the record system accordingly, adapt and implement. I just wanted to correct the impression that there were no complaints about broken backwards compatibility. Because it is - or at least, it can be - a real problem. Sometimes it has to be done in order to set things right, but it shouldn't be done lightly. There is also the issue of weighing down the language with features and extensions. It may give you more expressive power, but it also makes the language harder to master, and programs more difficult to maintain. Of course this would need an extension of the type checker Doesn't worry me overly, it is Somebody Else's Problem :-) -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: The Future of Haskell discussion at the Haskell Workshop
I'd like to add a voice of dissent here.
I would much prefer it if Haskell didn't add specific extensible records
support - even if it could be done without breaking backwards compatibility.
This is because I believe that extensible records encourage poor style. They
encourage people to expose the internal representation of their structures,
allowing users to match on internal fields rather than using accessor
functions.
One of the things that I like about the current Haskell record system is the
fact that record selectors are functions. This means that, if I change the
structure of a type, I can just replace the record selector with a normal
function.
On a similar line of argument, one change that I think would be nice would be
for record updaters to also be functions.
Then the following code
x {name1 = bla, name2 = blob}
would translate to the following:
set_name1 bla $ set_name2 blob $ x
This would allow record updates to be overridden in the same way that record
selectors can be.
Perhaps the best way to get the record extensibility features that people seem
to want would be to allow record selectors (and updaters) to be in type
classes, just like other functions.
So in summary, here is my proposal:
No specific extensible records system.
Define record update to be a function just like record selection is.
Allow these functions to be in type classes.
-Rob
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Hi! So in summary, here is my proposal: No specific extensible records system. Define record update to be a function just like record selection is. Allow these functions to be in type classes. I do not understand the second and third point: As I understand your idea, record selectors and updaters should still be defined by the datatype declaration. What does it then mean that they be allowed to be defined in type classes? Would that happen automatically? Cheers, /kff ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Hi!
So in summary, here is my proposal:
No specific extensible records system.
Define record update to be a function just like record selection is.
Allow these functions to be in type classes.
I do not understand the second and third point: As I understand your
idea, record selectors and updaters should still be defined by the
datatype declaration. What does it then mean that they be allowed
to be defined in type classes? Would that happen automatically?
I was thinking of something along the following lines:
class Wibble a where
wibble :: a - Int
wobble :: a - String
set_wibble :: Int - a - a
set_wobble :: String - a - a
data Foo = Foo {wibble :: Int, wobble :: String}
deriving Wibble
The Wibble class defines selector and updater functions for fields called
wibble and wobble.
When I define the datatype Foo, I give it fields called wibble and wobble,
which will define the functions in Wibble. If I say deriving Wibble then the
type system acknowledges that these functions are implementing the class
Wibble. If I had not derived Wibble then there would have been a name clash.
We could imagine the definition of Foo being automatically desugared to the
following:
data Foo = Foo Int String
instance Wibble Foo where
wibble (x,_) = x
wobbble (_,y) = y
set_wibble x (_,y) = (x,y)
set_wobble y (x,_) = (x,y)
Note that Wibble is a normal class. I could thus implement Wibble in a class
that was not a record. For example, the following, rather dull, implementation:
instance Wibble () where
wibble () = 3
wobble () = hello
set_wibble _ _ = ()
set_wobble _ _ = ()
Does that make things clearer?
-Rob
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1, ..., x_n
and the class mentioned declares operators y_1, ..., y_k
and set_y_1, ..., set_y_k where {y_1, ..., y_k} is a subset
of {x_1, ..., x_k}, of the appropriate types, then the
corresponding instance declarations are generated.
Cheers,
/kff
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1, ..., x_n
and the class mentioned declares operators y_1, ..., y_k
and set_y_1, ..., set_y_k where {y_1, ..., y_k} is a subset
of {x_1, ..., x_k}, of the appropriate types, then the
corresponding instance declarations are generated.
Yep.
It would also be possible for a class to declare only the selector or only the
updater for a field. E.g.:
class FooGet a where
foo :: a - Int
class FooSet a where
set_foo :: Int - a - a
data Bar = Bar {foo :: Int}
deriving (FooGet, FooSet)
-Rob
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
On Wed, 10 Sep 2003 10:26:04 +0100, Robert Ennals
[EMAIL PROTECTED] wrote:
class Wibble a where
wibble :: a - Int
wobble :: a - String
set_wibble :: Int - a - a
set_wobble :: String - a - a
data Foo = Foo {wibble :: Int, wobble :: String}
deriving Wibble
The Wibble class defines selector and updater functions for fields called
wibble and wobble.
When I define the datatype Foo, I give it fields called wibble and wobble,
which will define the functions in Wibble. If I say deriving Wibble then the
type system acknowledges that these functions are implementing the class
Wibble. If I had not derived Wibble then there would have been a name clash.
What would you do if Wibble had more functions than just those 4? You'd need
somewhere to put the implementations of the other functions for Foo.
Ganesh
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
Robert Ennals [EMAIL PROTECTED] writes:
[Heavy snippage, hopefully preserving semantics]
data Foo = Foo {wibble :: Int, wobble :: String}
deriving Wibble
We could imagine the definition of Foo being automatically desugared to the
following:
data Foo = Foo Int String
instance Wibble Foo where
wibble (x,_) = x
wobbble (_,y) = y
set_wibble x (_,y) = (x,y)
set_wobble y (x,_) = (x,y)
Shouldn't that rather be:
class HasWibble a where
wibble :: a - Int
set_wibble :: a - Int - a
class HasWobble a where ...
data Foo = Foo Int String
instance HasWibble Foo where
wibble (Foo x _) = x
set_wibble (Foo x y) z = Foo z y
instance HasWobble Fo where...
In order to let another record provide just a 'wibble' without a
'wobble'?
One danger of such an approach (implicit classes and instances) might
be non-intuitive error messages.
-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: The Future of Haskell discussion at the Haskell Workshop
[EMAIL PROTECTED] (Ketil Z. Malde) writes: Robert Ennals [EMAIL PROTECTED] writes: BTW, isn't this more or less exactly what Simon suggested (at the very top of this thread)? -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: The Future of Haskell discussion at the Haskell Workshop
On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote: Shouldn't that rather be: class HasWibble a where wibble :: a - Int set_wibble :: a - Int - a class HasWobble a where ... Or even: class HasWibble a b | a - b where wibble :: a - b set_wibble :: a - b - a class HasWobble a b | a - b where ... Best regards, Tom -- .signature: Too many levels of symbolic links ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
[EMAIL PROTECTED] (Ketil Z. Malde) writes: Robert Ennals [EMAIL PROTECTED] writes: BTW, isn't this more or less exactly what Simon suggested (at the very top of this thread)? Not really, no. I assume you mean the system suggested by Peter Thieman, outlined in the initial email by Henrik Nilsson. My system has the following differences: Record updaters become normal functions. (and recold selectors remain functions) Normal type classes are used to implement them. (no magic has constraints) Type classes are not magically inferred. They are manually declared just like any other type class would be. As I interpret it, the system proposed at the top of the thread treats record fields as something special, and I am very keen that this should not happen. I think that it is important that one should be able to replace a record field with accessor functions. -Rob ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
On Wed, Sep 10, 2003 at 02:27:33PM +0200, Ketil Z. Malde wrote: Shouldn't that rather be: class HasWibble a where wibble :: a - Int set_wibble :: a - Int - a class HasWobble a where ... Or even: class HasWibble a b | a - b where wibble :: a - b set_wibble :: a - b - a class HasWobble a b | a - b where ... It can be. The programmer can declare the type classes however they like. It is important to note that type classes are NOT automatically generated in my proposal. The type classes I describe are bog standard normal type classes. The only magic takes place when records are made instances of type classes, at which point the fields are translated into default instances. -Rob ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Future of Haskell: GUI development
[This is a summary on the GUI discussion at the Haskell workshop/HIM, as announced by Henrik Nilsson] The future development of GUI libraries for Haskell The development of Haskell applications with a graphical user interface has long been complicated by the large number of mostly incomplete libraries. In spring of this year people tried to focus the development effort and came up with the idea of a Common GUI API (CGA for short) which should define an intersection of three major platform APIs (Win32, Gnome/Gtk and Mac OS X) and that addresses the requirements of the platform's style guide (or human interface guidelines). The process of defining this CGA is a major undertaking. The alternative is to use a readily available cross-platform API, like wxWindows, at the expense of creating applications that might violate a platform's style guide and the cannot make use of platform specific functionality. A quick poll at the Haskell workshop revealed that 1/3 of the people thought that the CGA approach is worthwhile, 2/3 thought that the cross-platform approach is adequate. Hence the CGA idea as it stands right now will not be pursued. The discussions at the Haskell Implementor Meeting (HIM) yielded some interesting options (or compromises) that could help to target and unify the development effort of the different library maintainers. In particular we would like to - focus development on wxWindows (in form of wxHaskell) as this cross-platform toolkit should be adequate for most needs - move the programming model of Yahu (Attribute/set/get functionality) into the Haskell library hierarchy so that other (GUI) libraries can use it. - exploit wxWindow's capability to extract platforms specific handles/objects. The goal is to use other libraries (like gtk+hs, gtk2hs, Mocca, etc.) if wxWindows does not provide the needed functionality. - mention the names of the maintainers of each GUI library on the Haskell web site so that programmers can estimate how well-maintained a library is. Update these names regularly. In case people feel inclined to still pursue the CGA idea, one of the following two routes could be taken: - re-expose parts of wxHaskell in a way that forces the user to write applications that look and feel native on different platforms, i.e. a Common GUI API on top of wxWindows - write a GUI Builder application for Haskell; it would surely make Haskell itself more attractive as a rapid development language (such a Builder could also cater for the look-and-feel requirements of the different platforms) Please send any comments or critics to [EMAIL PROTECTED] . All input (and development effort) is welcome. Axel (on behalf of the GUI Task Force). ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Future of Haskell records
I'm quite happy to have Haskell records remain the way they are. I've used ML quite a lot, which of course has records without constructors. But the problem with this is that (1) you get massive error messages; (2) there isn't a mechanism for filling in empty slots. I don't think you really gain anything except the labour of not typing the constructor name. On the other hand, you would lose the Haskell feature by which when several constructors all have a record of the same name with the same type, you can extract that record in one operation. This is occasionally really useful, see the spaceships paper in this year's Haskell workshop. I am definitely against anything which breaks code in any major way, as I'm sitting on top of 90,000 lines of Haskell, which uses records a lot. (I like records.) Perhaps the only things which could be improved would be : (1) when some constructors have a field of type X, and others do not, it would be nice to have a way of getting a Maybe X value out. (2) I wish there were some way of allowing constructors for different types to share a record name. But perhaps the overloading required would make this not worthwhile. However neither (1) nor (2) is a priority for me. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
Simon Marlow [EMAIL PROTECTED] writes:
Of course, if we change the language that is implied by -fglasgow-exts now,
we risk breaking old code :-) Would folk prefer existing syntax extensions
be moved into their own flags, or left in -fglasgow-exts for now? I'm
thinking of:
- implicit parameters
- template haskell
- FFI
- rank-N polymorphism (forall keyword)
- recursive 'do' (mdo keyword)
The obvious approach is to do both (in exactly the manner of
{-fffi, -farrows, -fwith}), namely to introduce a separate flag
for each extension, but (temporarily) retain -fglasgow-exts as
a catch-all for the complete set. Eventually, -fglasgow-exts
could disappear.
With this suggestion, I would certainly be in favour of separate
flags for existing extensions.
Regards,
Malcolm
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
I agree with Malcolm, with the possible addition of:
keep -fglasgow-exts as it is (or, even, perhaps continue making it the
add all extensions keyword). also have -fffi, -farrows, -fth, etc.
but also have, -fnoth and -fnoffi. that way, if a lot of us have code
that uses all the extensions other than TH and have lots of code that
looks like (foo$bar), we can just to -fglasgow-exts -fnoth.
seems to be a win-win.
The obvious approach is to do both (in exactly the manner of
{-fffi, -farrows, -fwith}), namely to introduce a separate flag
for each extension, but (temporarily) retain -fglasgow-exts as
a catch-all for the complete set. Eventually, -fglasgow-exts
could disappear.
With this suggestion, I would certainly be in favour of separate
flags for existing extensions.
Regards,
Malcolm
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
--
--
Hal Daume III | [EMAIL PROTECTED]
Arrest this man, he talks in maths. | www.isi.edu/~hdaume
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
On Wednesday 10 September 2003 07:22 am, Hal Daume III wrote: I agree with Malcolm, with the possible addition of: keep -fglasgow-exts as it is (or, even, perhaps continue making it the add all extensions keyword). also have -fffi, -farrows, -fth, etc. but also have, -fnoth and -fnoffi. that way, if a lot of us have code that uses all the extensions other than TH and have lots of code that looks like (foo$bar), we can just to -fglasgow-exts -fnoth. seems to be a win-win. I agree; I want a catch-all flag, but I also want to flexibility to be able to pick and choose. Both -ffeature and -fnofeature is the way to go IMHO. A -- Andy Moran Ph. (503) 626 6616, x113 Galois Connections Inc. Fax. (503) 350 0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005[EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell for non-Haskell's sake
Hal (and other interested parties): I used Haskell to implement a model checker for a group of logics of time and knowledge. In practice these are a bunch of extensions to the classic CTL algorithms implemented in SMV [1]. The program itself (in terms of LOC) looks mostly like a compiler, and so the standard arguments apply. However, Haskell is absolutely perfect for implementing the SMV algorithms (and our variants) as they are cast in terms of fixpoints of boolean functionals. Moreover performance isn't an issue as a C library does the heavy lifting. (The program uses BDDs at the moment.) WRT Haskell, the only worry I had was that the program might leak space in difficult-to-resolve ways, and the usual problem of BDD variable ordering being difficult to control. cheers Peter. [1] SMV itself is actually a LISP program written in C. (I think this is self-evident from even a cursory glance, but the real giveaway is their AST: who else, apart from a seasoned LISP hacker, would use CONS cells for everything?) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The Future of Haskell discussion at the Haskell Workshop
On Wednesday 10 September 2003 10:51, Ketil Z. Malde wrote: And now, let's just screw any backwards compatibility, and re-engineer the records system¹. I don't need any of this, and it makes my life harder. Are you guys going to keep at it, until I regret ever using Haskell? I can't speak for any Haskell implementors or whether or not they intend to keep going at it. But maybe there are people who will regret ever using Haskell if nothing is done about the current records/modules situation (me for one). I don't mind waiting a while, if it's still unclear what should be done or can reasonably done given current state of the art re. the necessary type theory. But my understanding of the original summary was that I might as well give up hope of ever seeing anything like this in Haskell, for fear of upsetting the status quo. I don't like that idea much. I think if you want to use a language which is close to state of the art you have to accept some change. Better this than see it permanently crippled by backwards compatibility constraints. That said, I don't see why any backwards compatibility problems can't be managed with suitable compiler switches or whatever, which seems to be what Simon.M. is proposing for ghc. Regards -- Adrian Hey ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
GHC code generation
In an exchange of ideas with a friend, this question arose: [[ I've been looking at GHC, and it looks like it has generates machine code directly rather than via C--. I know that Simon Peyton Jones (famous in the Haskell world) is one of the authors of C--, but I can find no direct connection between this and GHC or Haskell. Have you any idea where I might find this connection? ]] In my discussion with him, I had assumed that GHC generates code via C-- and a version of the GCC compiler (why else is GCC part of the GHC installation?). Can anyone shed any light or pointers? Thanks. #g Graham Klyne [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GHC code generation
There is no C-- backend for GHC (search the mailing list and you'll see Simon asking someone to try to do this :P). GHC either generates code by itself, or generates normal C code (with -fvia-c or -O2, iirc) and then uses GCC to compile this. On Wed, 10 Sep 2003, Graham Klyne wrote: In an exchange of ideas with a friend, this question arose: [[ I've been looking at GHC, and it looks like it has generates machine code directly rather than via C--. I know that Simon Peyton Jones (famous in the Haskell world) is one of the authors of C--, but I can find no direct connection between this and GHC or Haskell. Have you any idea where I might find this connection? ]] In my discussion with him, I had assumed that GHC generates code via C-- and a version of the GCC compiler (why else is GCC part of the GHC installation?). Can anyone shed any light or pointers? Thanks. #g Graham Klyne [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Circular Instance Declarations
On Sun, 7 Sep 2003, Ashley Yakeley wrote: In article [EMAIL PROTECTED], Brandon Michael Moore [EMAIL PROTECTED] wrote: Detecting circularity in a derivation is equivalent to accepting a regular infinite derivation for instances. Would you have a use for irregular derivations? Could you give me an example? I should have asked whether you needed irregular types, and undecidable instances for irregular types. I'm close to a proof that will justify more permissive instances for regular types (plus a bit), but I haven't made much progress on irregular types. I'm wondering if anyone actually uses them, let alone fancy instances for them. Also, if I tried to expand my approach to irregular types it would require generating dictionaries a runtime, rather than just defining dictionaries recursively. In case the word irregular is the problem I'll give my definition, and how I'm applying it to types. The definition is from Pierce, in Types and Programming Languages. An irregular tree is a tree with an infinite number of distinct subtrees. When I say a type is irregular I mean the infinite trees you get when you (recursively) expand all the applications of type constructors is irregular. A simple irregular type is Irr a = Con a (Irr (F a)) (as long as F uses a) This expands to something like a|F a|F (F a)| ..., where t|t..t denotes a sum type. Each right child is like the parent with an extra F everywhere, so the tree is irregular. The sort of instance I'm interested in is something like instance (Eq a,Eq (Irr (F a)) = Eq (Irr a) where the context only mentions (subexpressions of) type expressions encoutered while expanding the type. Are you using anything like this? Brandon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Type Class Problem
Hello everyone I think I'm close to useful results on the instance restrictions. First there's an obvious extension to the Haskell98 rule. The H98 rule says the instance head must be a type constructor applied to type variables, and the context must mention only those type variables. This gives a termination proof by counting constructors. If the rule is weakened to allow an arbitrary type expression in the head and require that the context mention only strict subexpressions of the head, the same proof still applies. I'm not sure how useful this is, but we might as well allow it. Second, I have half a result in the direction of allowing the context to mention types that arise from applying type constructors used in the instance head. This requires accepting regular derivations, which means the compiler would need to track all previous goals while deriving an instance, and handle a second occurance of a goal by producing a reference to the dictionary for the first occurance (which may not be constructed yet), rather than blindly continuing the derivation. First I will explain the proof method. It's related to structural induction, but not quite the same. Suppose we have a subexpression relation on type expressions such that every type expression has only a finite number of subexpressions. If instance contexts only mention subexpressions of the head, then searching for an instance for a type can only generate #of subexpressions*#of classes distinct goals. Therefore, in finite time either the derivation will fail, or we will product a regular derivaiton. Alternately, we only try to derivive an instance the first time it arises as a goal, so each time we apply an instance rule there is one less goal in the pool of possible goals, which must eventually be exhausted. The syntactic subexpression relation obviously has these properties, but it's often useful to refer to types that show up when we apply type constructors. For example, my case and a simplification of Ashley's: data Mu f = In (f (Mu f)) instance C (f (Mu f)) = C (Mu f) On the other hand, we can't unfold all type constructors because some types are irregular, or, we encounter an infinite number of types while expanding the type constructors. Define a kind indexed family of predicates on type constructors, R_K(T), where the property is true if T::K, T is regular (including expanding the insides of lambdas), and if K=K1-K2, then R_K2(T t) for all t such that R_K1(t). Say a type is regularity preserving if it satisfies the predicate corresponding to its kind. Any type expression build entirely from regularity preserving type constructors will be regular. I think that a subexpression relation that allows expanding applications regularity preserving type constructors will give any type a finite number of subexpressions, but I don't know enough about the structure of regularity preserving type constructors to prove it. The missing half here is an algorithm for testing whether a type constructor is regularity preserving. For this the body of the type constructor can be simplified to consist of just the type constructor applications in the body. Apply the type constructor to skolem arguments, and check whether the resulting tree is regular. I don't know how to do this. Another approach is to draw out a dependency graph between type constructors, with an edge from A to B for each use of B in the definition of A, labeled with the arguments used. Then the question is whether starting from out type applied to tyvars we can find some path through the graph that generates an infinite number of types, where we keep track of the current node and the current arguments, and modify the arguments as directed by a label when moving along an edge. I don't know if the search can even a tail repeating path that witnesses the irregularity, let alone a family of paths that can be tested. Any assistance here would be appreciated. Thanks Brandon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Request for Instances
Hi everyone. I've been looking at the restrictions on instances in the H98 standard and thinking about alternatives. I would like to have a body of data type and class/instance declarations so I can test how useful various extensions would be. Please send or direct me to code that requires -fallow-undecidabe-instances. Thanks. Brandon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
At 13:13 10/09/03 +0100, Simon Marlow wrote: Of course, if we change the language that is implied by -fglasgow-exts now, we risk breaking old code :-) Would folk prefer existing syntax extensions be moved into their own flags, or left in -fglasgow-exts for now? I'm thinking of: - implicit parameters - template haskell - FFI - rank-N polymorphism (forall keyword) - recursive 'do' (mdo keyword) My 2p is that extensions that might be regarded as mainstream would usefully be included in a single easy-to-use switch like -fglasgow-exts. I think the only part I use from the above list is rank-N polymorphism, and that is imported from useful libraries. Where do multi-parameter classes fit in? #g Graham Klyne [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Circular Instance Declarations
In article [EMAIL PROTECTED], Brandon Michael Moore [EMAIL PROTECTED] wrote: A simple irregular type is Irr a = Con a (Irr (F a)) (as long as F uses a) Would this be an irregular type, with F as ((-) val)? data SymbolExpression sym val a = ClosedSymbolExpression a | OpenSymbolExpression sym (SymbolExpression sym val (val - a)); I used to use this in HScheme for expressions with free variables, as in the lambda calculus. For instance, \x.xy has y as a free variable, and might be represented as something like this: OpenSymbolExpression y (ClosedSymbolExpression (\y - (\x - x y))) It's very clean and safe, and can be made an instance of FunctorApplyReturn, but it turned out to be a bit slow. I also tried this: data ListSymbolExpression sym val a = MkListSymbolExpression [sym] ([val] - a); MkListSymbolExpression [y] (\[y] - (\x - x y)) This is much simpler, but now one has to make sure that the lists are the same size, so to speak. But this one turned out to be the fastest: newtype FuncSymbolExpression sym val a = MkFuncSymbolExpression ((sym - val) - a); MkFuncSymbolExpression (\f - (\x - x (f y))) The downside is that there's no way to find out what the free variables are. That's OK for Scheme, however, since Scheme doesn't complain about unbound variables until run-time. So, um, any excuse to talk about HScheme anyway. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)
In article [EMAIL PROTECTED], Graham Klyne [EMAIL PROTECTED] wrote: - implicit parameters - template haskell - FFI - rank-N polymorphism (forall keyword) - recursive 'do' (mdo keyword) ... Where do multi-parameter classes fit in? I think some of the type extensions such as rank-N and multi-parameter classes could be grouped under a single flag. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Circular Instance Declarations
On Wed, 10 Sep 2003, Ashley Yakeley wrote: Brandon Michael Moore [EMAIL PROTECTED] wrote: A simple irregular type is Irr a = Con a (Irr (F a)) (as long as F uses a) Would this be an irregular type, with F as ((-) val)? data SymbolExpression sym val a = ClosedSymbolExpression a | OpenSymbolExpression sym (SymbolExpression sym val (val - a)); This would be an irregular type. In my proposal an instance declaration deriving some instance of SymbolExpression sym val a could use the types sym val and a in the context, but not (val - a) which would only arise from unfolding the type constructor. Of course when I say proposal I mean Would be a proposal if only I could prove that last lemma. I used to use this in HScheme for expressions with free variables, as in the lambda calculus. For instance, \x.xy has y as a free variable, and might be represented as something like this: OpenSymbolExpression y (ClosedSymbolExpression (\y - (\x - x y))) It's very clean and safe, and can be made an instance of FunctorApplyReturn, but it turned out to be a bit slow. I also tried this: data ListSymbolExpression sym val a = MkListSymbolExpression [sym] ([val] - a); MkListSymbolExpression [y] (\[y] - (\x - x y)) This is much simpler, but now one has to make sure that the lists are the same size, so to speak. But this one turned out to be the fastest: newtype FuncSymbolExpression sym val a = MkFuncSymbolExpression ((sym - val) - a); MkFuncSymbolExpression (\f - (\x - x (f y))) The downside is that there's no way to find out what the free variables are. That's OK for Scheme, however, since Scheme doesn't complain about unbound variables until run-time. So, um, any excuse to talk about HScheme anyway. It looks like your scheme puts the type system to good use. I used a value type with numbers, Val-Val functions, and some other stuff. I gave up when I realized I needed to thread references through everything to implement R5RS. I suppose everyone has started a Scheme in Haskell sometime. Brandon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Circular Instance Declarations
A simple irregular type is Irr a = Con a (Irr (F a)) (as long as F uses a) The sort of instance I'm interested in is something like instance (Eq a,Eq (Irr (F a)) = Eq (Irr a) where the context only mentions (subexpressions of) type expressions encoutered while expanding the type. Are you using anything like this? In Haskell terms (making things slightly more general): data Irr a f = Con a (Irr (f a)) instance (Eq a,Eq (Irr (f a)) = Eq (Irr a f) The above instance is inherently dangerous (cause context reduction becomes non-terminating). I haven't seen the code attached to the instance. My guess is that if you could state something like the following instance (Eq a, (forall b. Eq b = Eq (f b))) = Eq (Irr a f) then your code type checks. Note that the above instance declaration is terminating. Unfortunately, such an extension does not exist at the moment. However, you can encode the above in ordinary Haskell. Check out Valery Trifonov's Haskell'03 paper Simulating Quantified Class Constraints. Martin ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Standalone Parser for Haskell Grammar
Hello! Does anyone know a reasonable standalone Parser for the Haskell Grammar? The only one i found was hsparser but it's still an alpha release and i get a few errors during compiling. I know i could write one using Happy but i don't want to reinvent the wheel... regards Peter ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Standalone Parser for Haskell Grammar
On Wed, Sep 10, 2003 at 12:33:50PM +0200, Peter Robinson wrote: Does anyone know a reasonable standalone Parser for the Haskell Grammar? The only one i found was hsparser but it's still an alpha release and i get a few errors during compiling. I know i could write one using Happy but i don't want to reinvent the wheel... The latest version of hsparser is the Language.Haskell.* modules in the haskell-src package, included with recent releases of GHC and Hugs. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
