> I thought nhc provided a reasonable subset of the Hugs-GHC libraries
> and, since the IO extensions are one of the first extensions people
> ask for, I assumed that if they provided anything they would certainly
> provide them.
Yes, nhc98 provides most of the popular IO extension functions,
inc
> Alastair:
> > The Hugs-GHC standard libs have them exported from IOExts.
Manuel:
> There is only one flaw: It doesn't work with nhc98.
Huh?
I thought nhc provided a reasonable subset of the Hugs-GHC libraries and, since the IO
extensions are one of the first extensions
people ask for, I assu
Alastair Reid writes (on the FFI mailing list):
> ps I wonder if it'd be possible to merge them by doing this
> in the hslibs repository:
>
> 1) Move the STG Hugs ifdefs out of the way:
>
>find . -name '*.[l]hs' | xargs perl -p -i
> -e's/__HUGS__/__STG_HUGS__/'
>
>The __HUGS__ label
"Alastair Reid" <[EMAIL PROTECTED]> wrote,
> > Without a standard way to get
> > at unsafePerformIO, such code would still rely on
> > non-standard features, which goers against the aim of
> > standardising the rest of the FFI.
>
> The Hugs-GHC standard libs have them exported from IOExts.
>
>
> Sadly, due to lack of support on the Hugs side, the Hugs/GHC extension
> libraries have drifted apart.
Sadly true.
But any parts of the standard that haven't changed in the last 2.5 years (e.g.,
unsafe{Perform,Interleave}IO) still work - so in
this case it can be relied upon.
Alastair
ps I
> > Without a standard way to get
> > at unsafePerformIO, such code would still rely on
> > non-standard features, which goers against the aim of
> > standardising the rest of the FFI.
>
> The Hugs-GHC standard libs have them exported from IOExts.
>
> Of course, the Hugs-GHC standard isn't an of
> Without a standard way to get
> at unsafePerformIO, such code would still rely on
> non-standard features, which goers against the aim of
> standardising the rest of the FFI.
The Hugs-GHC standard libs have them exported from IOExts.
Of course, the Hugs-GHC standard isn't an official Haskell l
"Simon Marlow" <[EMAIL PROTECTED]> wrote,
> > [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> >
> > > Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid
> > <[EMAIL PROTECTED]> pisze:
> > >
> > > > > Should these functions be available through the standard FFI?
> > > > > IMHO they should.
[
On Tue, 20 Mar 2001, Simon Marlow wrote:
> I'm not sure about including these functions in Foreign. Their
> location should be standardised, sure: but that's something to be
> discussed as part of the new library proposal. I don't feel they
> belong in Foreign.
So they can be provided somewher
> [EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
>
> > Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid
> <[EMAIL PROTECTED]> pisze:
> >
> > > > Should these functions be available through the standard FFI?
> > > > IMHO they should.
> > >
> > > I don't understand the question.
> > > Are y
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
>
> > > Should these functions be available through the standard FFI?
> > > IMHO they should.
> >
> > I don't understand the question.
> > Are you asking which module
On 18-Mar-2001, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Should these functions be available through the standard FFI?
IMHO: yes, they should be available, either through the standard FFI
or through some other standard module.
But it would be a good idea to document their semantics
Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> > Should these functions be available through the standard FFI?
> > IMHO they should.
>
> I don't understand the question.
> Are you asking which modules should export them?
Yes. IMHO they should be made as "standard" a
> Should these functions be available through the standard FFI?
> IMHO they should.
I don't understand the question.
Are you asking which modules should export them?
Alastair
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listin
Should these functions be available through the standard FFI?
IMHO they should.
Their functionality on a variety of concrete types can be archieved
by using C, in an ugly and inefficient way. FFI already contains the
level of unsafety they are at.
They are useful, especially in the context of FF
15 matches
Mail list logo
