Two bugs. Firstly, the notorious void type
newtype Void = Void Void
makes ghc -O go in an infinite loop in the strictness analysis phase.
Without optimization it works fine. (It would be very nice if Void could be
eliminated _completely_, ie. Void - a would have the same representation as
a
Oops - there is one more change needed:
add -package lang to HC_OPTS in lib/ghc/Makefile
I have not tried using it with Hugs.
Tim
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
G |- f :: all x::S . T G |- s :: S
--
G |- f s :: [s/x]T
Any more takers? I still don't have any pointers to literature where
this theorem notation is explained more fully, and I'd
Juan Carlos Arevalo Baeza wrote (on 28-05-01 18:02 -0700):
Just a very naive question, because I'm really curious. I've seen in
previous messages here discussions about type systems using this kind of
notation:
G |- f :: all x::S . T G |- s :: S
and not just type systems but also other aspects of operational
semantics. What we have here is a single rule from a rule-based
inductive definition of a certain relation G |- s :: S between typing
environments G, expressions s and types S.
It's probably worth mentioning here that this
CALL FOR PARTICIPATION
3rd Scottish Functional Programming Workshop
University of Stirling
Aug 22nd-24th, 2001
You are invited to participate in the 3rd Scottish Functional
Programming Workshop. The draft programme is below, and both registration
form and additional information are available at:
Another introduction, with emphasis on the historical development:
Philip Wadler, Proofs are Programs: 19th Century Logic and 21st
Century Computing.
http://www.cs.bell-labs.com/who/wadler/topics/history.html
It's a fun read, too.
Cheers,
Tom
Tom Pledger wrote:
I don't know whether this is a shining example of an advantage,
and am keen to see other comments.
For what it's worth, I've pulled some snippets from some code I wrote.
I wanted three recursive types which were nearly identical (Exp,ExpQv,ExpPr).
Rather than write three
Hello there. I've just released the first version
ofmy HOpenGL (Haskell Open Graphics Library) tutorial. I hope it will
encourage (and help) people around the world to use this great library/binding.
I also would like to hear some feedback from you. You can visit the tutorial
at:
That's a very nice visualization - exactly the kind of thing I was hoping
for. I grabbed your papers and will look over them for more information,
thanks very much for taking the trouble! The animations you sent me - and
the ones on your page - are really nice; it would be nice to have a system
Marcin Kowalczyk:
BTW, before I knew Haskell I exprimented with a syntax in which 'x f'
is the application of 'f' to 'x', and 'x f g' means '(x f) g'. Other
arguments can also be on the right, but in this case with parentheses,
e.g. 'x f (y)' is a function f applied to two arguments.
Hmmm.
David Bakin wrote:
That's a very nice visualization - exactly the kind of thing I was hoping
for. I grabbed your papers and will look over them for more information,
thanks very much for taking the trouble! The animations you sent me - and
the ones on your page - are really nice; it would
Jerzy Karczmarczuk [EMAIL PROTECTED] writes:
BTW, before I knew Haskell I exprimented with a syntax in which 'x f'
is the application of 'f' to 'x', and 'x f g' means '(x f) g'.
Hmmm. An experimental syntax, you say...
Oh, say, you reinvented FORTH?
Wouldn't
x f g
in a Forth'ish
On Tuesday, May 29, 2001, at 04:44 PM, Ketil Malde wrote:
Jerzy Karczmarczuk [EMAIL PROTECTED] writes:
Wouldn't
x f g
in a Forth'ish machine mean
g(f,x) -- using standard math notation, for a change
rather than
g(f(x))
?
In PostScript, a Forth derivative, it
29 May 2001 22:44:38 +0200, Ketil Malde [EMAIL PROTECTED] pisze:
Wouldn't
x f g
in a Forth'ish machine mean
g(f,x) -- using standard math notation, for a change
rather than
g(f(x))
?
It depends whether f changes the value at top of the stack or only
puts
15 matches
Mail list logo
