On Tue, 9 Sep 2003, Adrian Hey wrote:
I rarely use named fields in my Haskell progs with Haskell as it is ...
but you sure agree records are useful for collecting heterogenous data?
for example, see data DynFlags here:
Hello,
I may be wrong but can't we keep old records and add new ones (as
proposed in the First Class Modules paper)
with a different syntax?
Ussual records and extensible records are both usefull, in different
cases.
Best regards,
Nicolas Oury
Le mardi, 9 sep 2003, à 14:52 Europe/Paris,
HOpenGL, a Haskell binding for OpenGL and GLUT
version 1.05
I am pleased to announce the sixteenth release of the Haskell binding
for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the*
industrial strength 3D graphics API and a GUI toolkit.
On Tuesday 09 September 2003 13:52, Johannes Waldmann wrote:
On Tue, 9 Sep 2003, Adrian Hey wrote:
I rarely use named fields in my Haskell progs with Haskell as it is ...
but you sure agree records are useful for collecting heterogenous data?
Yes, I would agree that even the current
hello,
i think records are very useful, and we don't use them much in haskell,
becuase the current record system is not very good.
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
Coming from the ML world, I can say that I find the lack of
proper records a real loss. It is extremely convenient to
write functions which take many parameters as taking a record,
for then you don't have to worry so much about the order
of arguments. SML gets this much right, but the ad hoc
(We apologize for the reception of multiple copies)
*** CALL FOR PARTICIPATION **
Second International Symposium on
Formal Methods for Components and Objects
(FMCO 2003)
DATES 4 - 7 November
Hi.
Here's another opinion for the Records! Records! chorus:
- The record and module system is one of the two big things I'd like
to see changed in Haskell. (OT: the other is subtyping.)
- It shouldn't happen before Haskell 2, because of backward
compatability. (The dot operator
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
On Monday, Sep 8, 2003, at 03:53 US/Pacific, Simon Peyton-Jones wrote:
Consider an instance decl like:
instance (Lte a b l,If l b a c) = Max a b c
(This is a real example.) Notice that l is used on the LHS of the
= but not the RHS. The idea is that l will get unified by a
functional
Simon said
This is a tricky one. Here's what is going on.
I believe there's nothing tricky going on.
Your type annotation
g :: (F a b,D b (T r)) = (a,T r)
g = f
is simply incorrect. Keep in mind that GHC does NOT improve
type annotations. For example,
g :: (F a b, C (T r)) = (a,T r)
g =
On Tuesday, Sep 9, 2003, at 00:40 US/Pacific, Martin Sulzmann wrote:
Your type annotation
g :: (F a b,D b (T r)) = (a,T r)
g = f
is simply incorrect.
I must say I don't understand. I need a value of that type. In the
original, g is actually a method in a class, and its definition is in
an
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: Open
Resolution: None
Priority: 5
Bugs item #802366, was opened at 2003-09-08 10:06
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802366group_id=8032
Category: Compiler
Group: 6.0.1
Status: Closed
Resolution: Fixed
Priority: 5
Bugs item #802692, was opened at 2003-09-08 21:40
Message generated for change (Comment added) made by hampusr
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=802692group_id=8032
Category: hslibs/text
Group: 6.0.1
Status: Open
Resolution: None
Priority: 5
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: Open
Resolution: None
Priority: 5
When building the current version of GHC from CVS without having alex
installed, the build tries to use alex-inplace instead, but
apparently the dependency that tells make(1) to build that executable
before using it is missing. I had to execute
make ProjectsThatExist=alex
in the
| typecheck/TcSimplify.lhs:22:
| Module `TcUnify' (hi-boot interface) does not export
`unifyTauTy'
| make[1]: *** [stage2/typecheck/TcSimplify.o] Error 1
| make[1]: Leaving directory
`/usr/local/src/ghc-current/ghc/compiler'
| make: *** [stage2] Error 2
This is now fixed.
Peter Simons wrote:
[...]
| typecheck/TcSimplify.lhs:22:
| Failed to load interface for `TcUnify':
| Bad interface file: stage2/typecheck/TcUnify.hi-boot-6
| stage2/typecheck/TcUnify.hi-boot-6:6: parse error on input `.'
|
| typecheck/TcSimplify.lhs:22:
| Module
simonmar:
On Sat, 6 Sep 2003, Donald Bruce Stewart wrote:
simonmar:
I was a bit too soon reporting the sparc-sun-solaris2, two
attempts have died with stg_ap_v_ret. Same result
sparc-*-openbsd.
Also with mips-sgi-irix65 . An attempt died with stg_ap_v_ret .
I'm
On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote:
Looks like that was it!
I've just built a working unreg compiler on
sparc-unknown-openbsd, which I have not been able to do previously.
Is that using the instructions in the users guide and without having to
copy .hi
igloo:
On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote:
Looks like that was it!
I've just built a working unreg compiler on
sparc-unknown-openbsd, which I have not been able to do previously.
Is that using the instructions in the users guide and without having
dons:
simonmar:
Aha! I *think* I've figured out what's going wrong.
The stg_ap_v_ret failure is caused by info tables being generated for
the wrong endianness. This isn't supposed to happen, because we should
be cross-compiling for the correct endianness, but I'm guessing that the
Dnia ro 27. sierpnia 2003 20:48, Eugene Nonko napisa:
Are there any plans to extend Haskell parser to support prefix and
postfix operators? It will be just great for domain-specific languages.
It always kind of bothered me that unary minus is special.
Having only infix operators has the
24 matches
Mail list logo
