[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex

2003-09-10 Thread SourceForge.net
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

Re: Weird Undecidable Instances Bug

2003-09-10 Thread Martin Sulzmann
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

[ ghc-Bugs-792761 ] rts_getBool: not a Bool

2003-09-10 Thread SourceForge.net
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

RE: Segmentation fault with GHCi 6.0

2003-09-10 Thread Simon Marlow
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]

[ ghc-Bugs-802692 ] SIGSEGV in Text.Regex

2003-09-10 Thread SourceForge.net
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

[ ghc-Bugs-759910 ] Non-exhaultive patterns from derived Read

2003-09-10 Thread SourceForge.net
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

RE: stg_ap_v_ret porting crash: solved?

2003-09-10 Thread Simon Marlow
$ 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

Re: stg_ap_v_ret porting crash: solved?

2003-09-10 Thread Ian Lynagh
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

Re: stg_ap_v_ret porting crash: solved?

2003-09-10 Thread Donald Bruce Stewart
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

Re: stg_ap_v_ret porting crash: solved?

2003-09-10 Thread Matt Chapman
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Adrian Hey
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Ketil Z. Malde
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Johannes Waldmann
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Ketil Z. Malde
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Robert Ennals
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Karl-Filip Faxen
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Robert Ennals
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Karl-Filip Faxen
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Robert Ennals
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,

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Ganesh Sittampalam
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Ketil Z. Malde
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Ketil Z. Malde
[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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Tomasz Zielonka
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Robert Ennals
[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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Robert Ennals
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 ::

Future of Haskell: GUI development

2003-09-10 Thread Axel Simon
[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

Future of Haskell records

2003-09-10 Thread George Russell
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

Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)

2003-09-10 Thread Malcolm Wallace
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

Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)

2003-09-10 Thread Hal Daume III
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

Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)

2003-09-10 Thread Andy Moran
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.

Re: Haskell for non-Haskell's sake

2003-09-10 Thread Peter Gammie
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

Re: The Future of Haskell discussion at the Haskell Workshop

2003-09-10 Thread Adrian Hey
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

GHC code generation

2003-09-10 Thread Graham Klyne
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

Re: GHC code generation

2003-09-10 Thread Hal Daume III
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

Re: Circular Instance Declarations

2003-09-10 Thread Brandon Michael Moore
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

Type Class Problem

2003-09-10 Thread Brandon Michael Moore
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

Request for Instances

2003-09-10 Thread Brandon Michael Moore
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

Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)

2003-09-10 Thread Graham Klyne
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

Re: Circular Instance Declarations

2003-09-10 Thread Ashley Yakeley
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 |

Re: Syntax extensions (was: RE: The Future of Haskell discussion at the Haskell Workshop)

2003-09-10 Thread Ashley Yakeley
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

Re: Circular Instance Declarations

2003-09-10 Thread Brandon Michael Moore
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 |

Re: Circular Instance Declarations

2003-09-10 Thread Martin Sulzmann
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.

Standalone Parser for Haskell Grammar

2003-09-10 Thread Peter Robinson
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

Re: Standalone Parser for Haskell Grammar

2003-09-10 Thread Ross Paterson
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