Hi all,
I'm in the middle of writing kind inference for haskell, as part of a
type checker/inferer. After reading the section in the haskell report about
kind inference (section 4.6), I began to wonder why kind inference must
be done in dependency order.
Some friends and I came up with the foll
Dylan Thurston wrote:
>
>
> These sound great to me. If Haskell/2 is indeed open to such changes,
> would also be possible to revamp the numeric modules? As a
> mathematician, I get annoyed by such things as
>
> * (+) and (-) being lumped in with (*) (doesn't anyone use vector spaces?)
>
>
On Tue, 6 Feb 2001, Dylan Thurston wrote:
> On Tue, Feb 06, 2001 at 03:25:11PM +0100, Koen Claessen wrote:
> > What do people think about this? If people prefer these
> > stylistic changes, I think we should not hesitate making
> > them for Haskell/2 by completely redesigning the module
> > struc
Is there any documentation on using the FFI in the just released Hugs beta?
For example, what steps should I take to call the following C function?
#include
void Hello () { printf ("Hello from C"); }
Erik
___
Haskell mailing list
[EMAIL PROT
nubie nubie writes:
|
| --- Tom Pledger <[EMAIL PROTECTED]> wrote:
| > That line of reasoning establishes that e is constrained on the right
| > hand side of the "=". However, it's still bound (by an implicit
| > "forall e") on the left hand side of the "=". The problem is that e
| > can
[Andrew Tolmach <[EMAIL PROTECTED]>]
>
>
> Indeed, I plan to publish a draft specification (quite soon) and
> will be delighted to get feedback from the community before
> investing heavily in implementation. I'm very glad to hear
> that others are interested!
>
i'm also quite interested in
On Tue, Feb 06, 2001 at 10:29:36PM +0100, Andreas Gruenbacher wrote:
> On Tue, 6 Feb 2001, Dylan Thurston wrote:
> > * (+) and (-) being lumped in with (*) (doesn't anyone use vector spaces?)
>
> That also causes me some headaches.
>
> ... Even for others, it might be scaling (s
> -> t -> t).
>
On Tue, 6 Feb 2001, Dylan Thurston wrote:
> On Tue, Feb 06, 2001 at 03:25:11PM +0100, Koen Claessen wrote:
> > What do people think about this? If people prefer these
> > stylistic changes, I think we should not hesitate making
> > them for Haskell/2 by completely redesigning the module
> > struc
On Tue, Feb 06, 2001 at 03:25:11PM +0100, Koen Claessen wrote:
> What do people think about this? If people prefer these
> stylistic changes, I think we should not hesitate making
> them for Haskell/2 by completely redesigning the module
> structure and using more consistent naming conventions.
T
This is exactly what I proposed when fmap and the other weird names were
introduced. Hopefully there are more allies now.
Erik
- Original Message -
From: "Koen Claessen" <[EMAIL PROTECTED]>
To: "The Haskell Mailing List" <[EMAIL PROTECTED]>
Sent: Tuesday, February 06, 2001 6:25 AM
Subjec
Hello all,
I'm experimenting with the ST monad GHC/Hugs extension and came across a
puzzling omisson: in GHC 4.06 if I import the LazyST module instead of the
standard one then the knot-tying fixST combinator is not defined.
Aparently the reason for this omisson is not documented in the ghc m
> Haskell.org has a page "Job Adverts".
> http://www.haskell.org/jobs.html
I like the new scope. But to minimise confusion of people looking for
paid jobs (which now exist), why not reflect the explanations in the first
paragraph in the page structure? Two main sections should be sufficient,
wi
Johannes Waldmann wrote:
| Should this also apply to names in the standard
| library? like Monad (filterM, zipWithM ,..) I mean,
| theoretically yes, but is it feasible to change it?
Obviously, these functions should have been called:
Monad.filter, Monad.zipWith
The lazy programmer can t
On Tue, 6 Feb 2001, Stefan Karrmann wrote:
> > type Byte = Word8
>
> I would prefer
>
> type Octet = Word8
>
> to emphasise that the functions really uses 8 bits.
I would define Byte as something different on an architecture where the
basic file unit is not 8 bits. It's like char in C.
--
M
Marcin 'Qrczak' Kowalczyk schrieb folgendes am Tue, Feb 06, 2001 at 12:54:29PM +0100:
> On Tue, 6 Feb 2001, Olaf Chitil wrote:
>
> > I just see one problem with John's proposal: the type Byte.
>
> type Byte = Word8
I would prefer
type Octet = Word8
to emphasise that the functions really uses
> Style Warning! ... writeByte -> Byte.write
Yes yes yes please!
Often, if someone writes identifiersWithSuffix,
the suffix actually carries a type information or a module information,
and the programmer should use the type resp. module system
of the language to express that.
Should this also a
Marcin 'Qrczak' Kowalczyk wrote:
| IMHO it looks nicer to have Byte in function names, so
| there can be such type synonym too.
Style Warning!
Why do many people when designing libraries not make full
use of the Haskell module system? Instead of
writeByte
readByte
(or so), one could als
Marcin 'Qrczak' Kowalczyk wrote:
> type Byte = Word8
>
> IMHO it looks nicer to have Byte in function names, so there can be such
> type synonym too.
I agree that Byte is nicer than Word8.
So why is this type synonym not in the library Word of the FFI?
I think that is the right place for it.
-
Haskell.org has a page "Job Adverts".
http://www.haskell.org/jobs.html
This page lists university and industry positions for people who want to
work with Haskell.
However, besides that, it shall also contain other kinds of adverts.
Haskell is based on open source software to which a large numbe
On Tue, 6 Feb 2001, Olaf Chitil wrote:
> I just see one problem with John's proposal: the type Byte.
type Byte = Word8
IMHO it looks nicer to have Byte in function names, so there can be such
type synonym too.
I would call the module ByteIO or BinaryIO instead of cryptic BIO.
--
Marcin 'Qrcz
Simon Marlow wrote:
> > http://www.ugcs.caltech.edu/~john/computer/haskell/
>
> How about this slightly more general interface, which works with the new
> FFI libraries, and is trivial to implement on top of the primitives in
> GHC's IOExts:
>
> hPut :: Storable a => Handle -> a -> IO (
> There is actually NO way with haskell 98 to portably read and write
> binary files. and many libraries which provide this feature are
> inherently non portable, (they assume a Haskell Char = C char = byte)
> which is not necisarily the case. I wrote up a proposal for a binary
> file IO mechanism
22 matches
Mail list logo
