-fno-monomorphism-restriction

2004-11-24 Thread Christian Maeder
Hi,
I've a file ATC/Sml_cats.hs that does not compile (see below) with the 
flag -fno-monomorphism-restriction (ghc 6.2.2), whereas it compiles fine 
without that option. Since I want to use -fno-monomorphism-restriction 
for other files (from programatica) I've a problem, because there is no 
option -fmonomorphism-restriction that I could place inside of 
ATC/Sml_cats.hs.

If someone wants to reproduce the error, do the following:
1) check out HetCATS repository with:
cvs -d pserver:[EMAIL PROTECTED]:/repository co 
HetCATS
2) comment out variable HC_PACKAGE in the Makefile (to avoid dependency 
from uni)
3) add the flag -fno-monomorphism-restriction to the variable HC_FLAGS
4) call (GNU) make

Cheers Christian
Compiling ATC.Sml_cats ( ./ATC/Sml_cats.hs, ./ATC/Sml_cats.o )
./ATC/Sml_cats.hs:23:
Ambiguous type variable `a' in the top-level constraint:
  `ATermConvertibleSML a'
arising from use of `ad'' at ./ATC/Sml_cats.hs:2068
./ATC/Sml_cats.hs:23:
Ambiguous type variable `a1' in the top-level constraint:
  `ATermConvertibleSML a1'
arising from use of `aa'' at ./ATC/Sml_cats.hs:1501
./ATC/Sml_cats.hs:23:
Ambiguous type variable `a2' in the top-level constraint:
  `ATermConvertibleSML a2'
arising from use of `aa'' at ./ATC/Sml_cats.hs:1479
./ATC/Sml_cats.hs:23:
Ambiguous type variable `a3' in the top-level constraint:
  `ATermConvertibleSML a3'
arising from use of `las' at ./ATC/Sml_cats.hs:421
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: User-defined operators and compound expressions using Happy

2004-11-24 Thread Frank-Andre Riess
 On Mon, 2004-11-22 at 17:48 +0100, Frank-Andre Riess wrote:
 Hi there folks,

 once again, I've got a question related to Happy (I've got version 1.13
 at
 the moment).
 Maybe, it's even more a question on formal languages, but well...
 How can I write a grammar that can cope with user-defined operators (of
 different precedences/associativities

 One standard solution is to parse user defined operators as if they were
 all one precedence/associativity and then re-associate them later once
 you know what the precedence and associativity of each operator is.

 That way the parser grammar does not need to be adjusted on the fly.

 So you wold parse
 1+2*3
 as
 [LiteralInt 1, Op '+', LiteralInt 2, Op '*', LiteralInt 3]
 and then later turn that into
 BinOp '+' (LiteralInt 1) (BinOp '*' (LiteralInt 2) (LiteralInt 3))
 using your mapping of operators to precedence/associativity.

 Duncan

Thank you very much. What I did by now is more or less along the lines of
your suggestion, but it doesn't work to my satisfication yet. Might be due
to overloaded tokens, though (e.g. '|' is both a set union operator and
the seperator in case statements).
Maybe we'll need to redesign the syntax.
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: User-defined operators and compound expressions using Happy

2004-11-24 Thread Frank-Andre Riess
 On 2004 nov 22, at 17:48, Frank-Andre Riess wrote:

 Hi there folks,

 once again, I've got a question related to Happy (I've got version
 1.13 at
 the moment).
 Maybe, it's even more a question on formal languages, but well...
 How can I write a grammar that can cope with user-defined operators (of
 different precedences/associativities) and compound expression like
 function calls, if-then-else- and case-statements and the like. I
 tried to
 write it down straight forwardly, but failed terribly (alas, I didn't
 keep
 it, so I can't show you - if someone of you is versed in this issue, I
 can
 try to explain the language's constructs).

 One way of doing this using combinator based parsing (where you can
 generate parsers dynamically) is to read the fixity declarations, and
 to use the result of this to build the precedence parser. This idea has
 been sketched in:

   S. D. Swierstra and P. R. Azero Alcocer. Fast, Error Correcting Parser
 Combinators: a Short Tutorial. In J. Pavelka, G. Tel, and M. Bartosek,
 editors, SOFSEM'99 Theory and Practice of Informatics, 26th Seminar on
 Current Trends in Theory and Practice of Informatics, volume 1725 of
 LNCS, pages 111--129, November 1999.

 If you do not have access to this I will be happy to send it to you,

   Doaitse Swierstra

Thank you very much. I don't know much about combinator based parsing,
however (or maybe just therefor) I'm interested in having a closer look at
it. I'd be obliged if you sent me your paper.

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: ghc -e

2004-11-24 Thread Benjamin Franksen
On Wednesday 24 November 2004 02:39, Nils Anders Danielsson wrote:
 On Wed, 24 Nov 2004, Benjamin Franksen wrote:
  What about putting this thing on the Haskell Wiki?

 Feel free to do so. I recently noted that some version of GHC (6.3?)
 ships with a runghc program, so this problem will most likely disappear
 soon, though.

 http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/utils/rung
hc/runghc.hs

Nice to hear that. Publishing the code is obsolete then.

Ben
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Bug in touchForeignPtr?

2004-11-24 Thread Peter Simons
Duncan Coutts writes:

  you cannot solve the finalisers problem just by running
  the finaliser thread to completion (or it'd be done that
  way already!)

I guess, I was approaching the problem from the wrong side.
What I am really interested in are the implications of this
fact for the programmer. What I believe to have understood
so far is:

  You have no guarantee that a finalizer you registered
  will ever be run -- even if the program terminates
  normally.

Is that correct? Or did I misunderstand something?

Peter

___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users