RE: Modelling Java Interfaces with Existential data types
Ralf, I've read the paper (surprisingly it's quite new - Jun 2004) and your sample. Here are several comments: 1. It looks like your HList is basically a sugarized version of data AnyMyInterface = Impl1 MyImplementation1 | Impl2 MyImplementation2 with the same drawback: you require me to explicitly list all the possible implementations of my interface, while the existential version of AnyMyInterface accepts all the implementation, whenever they came from. It might be possible to load them via hs-plugins or to obtain using something similar to Clean Dynamics (btw, is there anything similar available for Haskell?). 2. There will also be problems in gluing the utility/legacy code. E. g. if I want to call any list function on HLists (e.g. reverse). The idea of having heterogeneous FiniteMap can be implemented by storing the single-element lists, but it will complicate the code, which will work with the map. 3. Your quality can indeed not work because the existentially quantified implementations are of course opaque. You can just compare apples and oranges. Why? The idea of equality testing (not comparing) seems to be easily applies to apples and oranges. Is an Apple equal to an Orange? No. Is big Apple equal to small Orange? No. Is small Apple equal to small Apple? Yes. (The exact answer depends on the application). I'm completely confident with applying (==) to different type. It's quite a common operation in OO-world. I would like to have the following behaviour: instance Eq AnyMyInterface where (==) (AnyMyInterface a1) (AnyMyInterface a2) = if (typeOf a1) == (typeOf a2) then false else a1 == a2 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Syntax for output-only arrows?
When I use arrows, I find that many of my primitives are of type (a () b)
(for some arrow type a): they produce a value but don't take any input.
E.g. deterministic parsers are like this.
The syntactic sugar for arrows is lovely, but I find it a bit tedious
writing foo - () all the time. The syntax allows the output of arrows
to be ignored, why not input too?
Would it cause unreasonable parsing problems simply to allow a simple
expression of an arrow type to be a legal command inside a proc
expression, with an implicit - () input? Or are there other reasons
against it?
I for one find it extremely convenient that I can write purely
imperative code with a simple syntax like do { foo; bar; baz }. I'd
like similar simplicity when dealing with arrows, too.
Lauri Alanko
[EMAIL PROTECTED]
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Glasgow Haskell on different versions of Linux
Dear Haskellers, since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 Unfortunately our network has machines with both of this glibc versions. The problem seems to be related with the inclusion of ctype.h. Is it possible to produce a GHC binary for glibc 2.3 that does not depend on ctype.h? I think such a binary (produced under glibc 2.3) would be executable also under linux with glibc 2.2 Currently ctype.h triggers the error under glibc 2.2 (if the glibc 2.3 binarias are used): /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by lib/i386-unknown-linux/ghc-6.2.1) and prevents linking under glibc 2.3 (if the glibc 2.2 release is used) Cheers Christian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
2004-06-08T14:17:22 Christian Maeder: since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 If it were possible to construct and ship a statically-linked ghc, that might be ideal; it should be portable across a wide range of Linuxes, regardless of what libc they have installed. Would even work on my Linux, which has no glibc at all, only uClibc (and so far I've been unsuccessful in my attempts to boostrap ghc in, boo-hoo). -Bennett pgpFGZqWmds5N.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Christian Maeder wrote: since version 6.2 we have 2 binary distributions for (generic) linux: for glibc 2.2 and glibc 2.3 Maybe this is no longer necessary. I've produced an installation (under glibc 2.2) that runs under glibc 2.2 and glibc 2.3. As also Volker Stolz suggested I've changed, after calling ./configure, a line in mk/config.h from #define HAVE_CTYPE_H 1 to /* #undef HAVE_CTYPE_H */ I'll try the same trick under glibc 2.3 later. Christian P.S. What is ctype.h good for? ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Glasgow Haskell on different versions of Linux
Christian Maeder wrote: What is ctype.h good for? A good question. Its only use seems to be in ghc/rts/RtsFlags.c where it is used for functions like isdigit and isspace for decoding the RTS flags. Maybe it should be retired altogether. I'm rather puzzled how this works if ctype.h isn't there at all, as it seems to. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Syntax for output-only arrows?
On Tue, Jun 08, 2004 at 03:47:04AM +0300, Lauri Alanko wrote:
When I use arrows, I find that many of my primitives are of type (a () b)
(for some arrow type a): they produce a value but don't take any input.
E.g. deterministic parsers are like this.
The syntactic sugar for arrows is lovely, but I find it a bit tedious
writing foo - () all the time. The syntax allows the output of arrows
to be ignored, why not input too?
Would it cause unreasonable parsing problems simply to allow a simple
expression of an arrow type to be a legal command inside a proc
expression, with an implicit - () input? Or are there other reasons
against it?
I for one find it extremely convenient that I can write purely
imperative code with a simple syntax like do { foo; bar; baz }. I'd
like similar simplicity when dealing with arrows, too.
ooh. I second this motion. if it is possible that is.
--
John Meacham - repetae.netjohn
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
