26 Jul 2000 19:30:42 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze:
instance (ForeignArg fa ha, Call ff hf) = Call (fa - ff) (ha - hf) where
callIO f = callIO . convertArg (\fa - f = return . ($fa))
BTW. I have not tested if it works nor thought how it would execute,
but I
[a while ago]
From: Tom Pledger
Claus Reinke writes:
- one would think that () simply takes its role as a unit, so that
(),a == a == a,()
but if we know x::() does that imply that x,a == a ?
x could be bottom, and the equations for the unit look strict in
their unit
Wed, 9 Aug 2000 20:27:14 +0100, Claus Reinke [EMAIL PROTECTED] pisze:
In the language I had in mind, I would expect to be able to "retrieve" the
() from any product, at any position
I still prefer the list-like non-associative treatment of tuples.
It needs not type system extensions.
The
Hi.
Claus Reinke writes:
- one would think that () simply takes its role as a unit, so that
(),a == a == a,()
but if we know x::() does that imply that x,a == a ?
x could be bottom, and the equations for the unit look strict in their
unit parameter, so probably not;
Fri, 28 Jul 2000 08:23:52 -0700, Simon Marlow [EMAIL PROTECTED] pisze:
It perhaps should be, but Int8 isn't a primitive type: it's implemented in
terms of Int#. There should really be 8-bit, 16-bit and 32-bit primitive
types in GHC
It's not a problem: writeInt8OffAddr could take Int#. I
Marcin 'Qrczak' Kowalczyk:
Ah, I was once doing such overloading of IO functions. I tried but
was not able to adapt it to "threaded" foreign calls.
Help! Now it looks easier, but still I can't get it.
You seem to like puzzles?-) I almost gave up on this one,
and now it looks so simple...
Wed, 26 Jul 2000 15:46:16 +0100, Claus Reinke [EMAIL PROTECTED] pisze:
class CallN sigF sig where
callN :: IO sigF - sig
AAA! Thank you, it works now!
Having IO in the argument here, together with doing the work inside
the argument of the recursive call, was The Lacking Idea.
If you are happy with the isomorphism
(T1 x T2 x ...) - (T1 x (T2 x (...)))
But in Haskell these are not isomorphic.
(a,b,c) is NOT isomorphic to (a,(b,c)), just think about bottom.
--
-- Lennart
Mon, 24 Jul 2000 09:04:58 +0100, Chris Angus [EMAIL PROTECTED] pisze:
i.e. rather than having a read / show method for each type
we have a generic one which "asks" the type which type it
actually is or requests a constructor by name.
Ugh, IMHO it's bad. Such operations should be overridable
Tue, 25 Jul 2000 09:02:36 +0200, Lennart Augustsson [EMAIL PROTECTED] pisze:
If you are happy with the isomorphism
(T1 x T2 x ...) - (T1 x (T2 x (...)))
But in Haskell these are not isomorphic.
(a,b,c) is NOT isomorphic to (a,(b,c)), just think about bottom.
data a :, b = a :, !b
Mon, 24 Jul 2000 22:19:36 +0100, Claus Reinke [EMAIL PROTECTED] pisze:
I only had a quick look at QForeign.hs, so I'm not sure whether
this will help (do you really need that odd chaining of conversion
functions?
Values of out parameters contribute to the result returned. Parameters
may
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 25 July 2000 09:30
To: [EMAIL PROTECTED]
Subject: Re: The type of zip
Mon, 24 Jul 2000 09:04:58 +0100, Chris Angus
[EMAIL PROTECTED] pisze:
I dont agree. To me it seems simply like a logical
25 Jul 2000 08:56:09 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze:
and why do you pass what seem to be conversion functions as
parameters, do they not follow from the types?),
Not always, e.g. char * may be in, out, or in/out parameter.
It will get hairy with Unicode.
But
Tue, 25 Jul 2000 10:16:24 +0100, Chris Angus [EMAIL PROTECTED] pisze:
eg. readDyn could have the signature
String - Dynamic
It's not possible. Which types are "registered" to be read that way?
What if types have conflicting printed representations?
around this area I'd be more interested
25 Jul 2000 08:56:09 GMT, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] pisze:
Ah, I was once doing such overloading of IO functions. I tried but
was not able to adapt it to "threaded" foreign calls.
Help! Now it looks easier, but still I can't get it.
Assume we have:
class Arg f h where
Lennart Augustsson:
If you are happy with the isomorphism
(T1 x T2 x ...) - (T1 x (T2 x (...)))
But in Haskell these are not isomorphic.
(a,b,c) is NOT isomorphic to (a,(b,c)), just think about bottom.
Right, thanks. I should have been more precise. On the right, "the"
product is
es [mailto:[EMAIL PROTECTED]]
Sent: 21 July 2000 17:29
To: 'Mark Tullsen'; Matt Harden
Cc: [EMAIL PROTECTED]
Subject: RE: The type of zip
| No doubt. But seriously, I was thinking of a "built-in" Zippable
| instance just like we have for Ord, Enum, Show, etc.
|
| That'
On 24-Jul-2000, Chris Angus [EMAIL PROTECTED] wrote:
Has anyone ever thought of trying to use reflection in these cases.
Yes, I've thought of it. That is how we implement the generic
`read' and `print' in Mercury. Using reflection like this
seems to be a quite powerful technique; I think that
At 06:33 PM 7/24/00 +1000, Fergus Henderson wrote:
On 24-Jul-2000, Chris Angus [EMAIL PROTECTED] wrote:
Has anyone ever thought of trying to use reflection in these cases.
Yes, I've thought of it. That is how we implement the generic
`read' and `print' in Mercury. Using reflection like this
Marcin 'Qrczak' Kowalczyk:
Also I was not able to unify callN series from
http://qrczak.ids.net.pl/qforeign.tar.gz (QForeign.hs).
I only had a quick look at QForeign.hs, so I'm not sure whether
this will help (do you really need that odd chaining of conversion
functions? and why do you pass
Claus Reinke wrote:
The problem with tuples is that each length of tuple comes as a separate
piece of *syntax* in Haskell, not built in a compositional way from tuples
of smaller length. Type classes enable meta-programming based on types,
but not based on syntax..
If you are happy with
Fri, 21 Jul 2000 09:29:11 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
http://research.microsoft.com/~simonpj/#derive
Ahhh! Looks like it covers the case of deriving for newtypes!
Does every currently derivable class fit into this?
I wonder if it's able to derive Dynamic, which
| No doubt. But seriously, I was thinking of a "built-in" Zippable
| instance just like we have for Ord, Enum, Show, etc.
|
| That's what I thought you meant. But since I have a pet peeve about
| how Haskell implementations work ...
Is your peeve related to the built-in "deriving"
Matt Harden wrote:
It has always seemed to me that having multiple zip functions with
different names (zip, zip3, zip4, etc..) was unfortunate, and a single
zip that handled all possible tuples would be better. Now, with
Multi-Parameter Type Classes and Functional Dependencies, we have an
Mark Tullsen wrote:
Matt Harden wrote:
o A Zippable class be created, defining zip and unzip for all tuple
types (or at least the first few)
For _all_ tuple types? That's a lot of instance declarations ;-)!
No doubt. But seriously, I was thinking of a "built-in" Zippable
instance
Matt Harden wrote:
Mark Tullsen wrote:
Matt Harden wrote:
o A Zippable class be created, defining zip and unzip for all tuple
types (or at least the first few)
For _all_ tuple types? That's a lot of instance declarations ;-)!
No doubt. But seriously, I was thinking of a
Thu, 20 Jul 2000 15:59:36 -0500, Matt Harden [EMAIL PROTECTED] pisze:
I was thinking of a "built-in" Zippable instance just like we have
for Ord, Enum, Show, etc.
What about zipWith, curry, uncurry, liftM, zipWithM?
Also I was not able to unify callN series from
Fellow Haskellers,
Please forgive my lack of brevity here.
It has always seemed to me that having multiple zip functions with
different names (zip, zip3, zip4, etc..) was unfortunate, and a single
zip that handled all possible tuples would be better. Now, with
Multi-Parameter Type Classes and
28 matches
Mail list logo
