Jules Bean <[EMAIL PROTECTED]> writes:
> Unless its possible to arrange haskell FFI bindings to have types in
> MonadIO rather than IO...
MonadIO is a class, not a type. Anyway, it's conceptually impossible
to wrap a computation of an arbitrary monad in the MonadIO class into
IO. It's not a techn
Wolfgang Thaller wrote:
>
> 2) Evaluation order.
>
> That's what everyone has been fighting about.
> [...]
>
>> The basic idea is that your entire program behaves as if in a giant
>> 'mdo' block, ordered in module dependency order.
>
>
>
> What is module dependency order? There's no such thing when
On 13 October 2004 03:36, Wolfgang Thaller wrote:
> b) Some predetermined order, with semantics like mdo:
>
> John Meacham wrote:
>
>> The basic idea is that your entire program behaves as if in a giant
>> 'mdo' block, ordered in module dependency order.
I also like the mdo idea - in fact it oc
There are stToIO and ioToST sunctions though (ioToST is unsafe)...
Keean
Jules Bean wrote:
On 13 Oct 2004, at 13:14, MR K P SCHUPKE wrote:
its almost commutative
Does that have something to do with splitting the supply?
That is an approach to getting unique values, I think.
newIORef
why not use
On 13 Oct 2004, at 13:14, MR K P SCHUPKE wrote:
its almost commutative
Does that have something to do with splitting the supply?
That is an approach to getting unique values, I think.
newIORef
why not use 'newSTRef' and use the ST monad...
In the context of my original question, the answer is that
>its almost commutative
Does that have something to do with splitting the supply?
>newIORef
why not use 'newSTRef' and use the ST monad...
Keean.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
On 12 Oct 2004, at 22:49, MR K P SCHUPKE wrote:
All we really need is a 'unique value monad' to give us unique values
This sounds a lot like Clean's unique-types?
No, that's a confusion of terminology.
'Unique types' are type which have only one member. 'RealWorld' in
haskell is rather like one of
On Wed, Oct 13, 2004 at 10:01:08AM +0100, Adrian Hey wrote:
> On Wednesday 13 Oct 2004 3:36 am, Wolfgang Thaller wrote:
> > b) Some predetermined order, with semantics like mdo:
> >
> > John Meacham wrote:
> > > The basic idea is that your entire program behaves as if in a giant
> > > 'mdo' block,
On Wednesday 13 Oct 2004 3:36 am, Wolfgang Thaller wrote:
> b) Some predetermined order, with semantics like mdo:
>
> John Meacham wrote:
> > The basic idea is that your entire program behaves as if in a giant
> > 'mdo' block, ordered in module dependency order.
>
> What is module dependency order?
Wolfgang Thaller <[EMAIL PROTECTED]> schrieb am 13.10.04 04:36:43:
> 2) Evaluation order.
>
> That's what everyone has been fighting about.
>
> So what are our options?
>
> a) unsafePerformIO - like.
> b) Some predetermined order, with semantics like mdo:
c) same as b) plus unsafeInterleaveIO
Well, Wadler's Law of Language Design has been disproved. We seem to
agree on the syntax, that is, global "foo <- bar" bindings, and we're
actually discussing semantics. That's great!
Just for the record, I want exactly what Adrian proposed.
There seem to be two interesting points about the sema
Vincenzo Ciancia wrote:
> > Unfortunately, in this case the whole point of what people are trying
> > to do with unsafePerformIO is to allow these things to be visible at
> > the top level :-)
>
> Sometimes I get too much involved in what I think about, and forget the
> original goal :) A littl
On Tuesday 12 Oct 2004 10:19 pm, Jules Bean wrote:
> It does matter for general IO operations at the top level.
All I'm aiming for is to disambiguate programs (avoid the use of
unsafePerformIO) in such a way that the programmer at least stands a
reasonable chance of getting it right without compil
On Wednesday 13 October 2004 00:00, Adrian Hey wrote:
> Unfortunately, in this case the whole point of what people are trying
> to do with unsafePerformIO is to allow these things to be visible at
> the top level :-)
Sometimes I get too much involved in what I think about, and forget the
original
On Tuesday 12 Oct 2004 10:47 pm, Marcin 'Qrczak' Kowalczyk wrote:
> Adrian Hey <[EMAIL PROTECTED]> writes:
> > The only real insanity with the current situation is the loss of
> > referential transparency implied by the use of unsafePerformIO,
> > which is why various pragma hacks and compiler swit
On Tuesday 12 Oct 2004 8:43 pm, Vincenzo Ciancia wrote:
> The objection was for cases like
>
> x :: Int <- someIOAction
> y :: Int = x + 1
>
> Note that both have Int type but the second is a pure value while the
> first is the result of a computation.
Well obviously if people are going to use it
>All we really need is a 'unique value monad' to give us unique values
This sounds a lot like Clean's unique-types?
Keean.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Adrian Hey <[EMAIL PROTECTED]> writes:
> The only real insanity with the current situation is the loss of
> referential transparency implied by the use of unsafePerformIO,
> which is why various pragma hacks and compiler switches need to be
> used (in order to prevent inappropriate substitutions).
On 12 Oct 2004, at 20:25, Adrian Hey wrote:
On Tuesday 12 Oct 2004 6:28 pm, Jules Bean wrote:
On 12 Oct 2004, at 14:08, Adrian Hey wrote:
x <- someAction
y <- someAction(x)
I would say keep things as they currently are with the
unsafePerformIO
solution, I.E. Order unspecified, the action that crea
On 12 Oct 2004, at 18:59, Marcin 'Qrczak' Kowalczyk wrote:
Jules Bean <[EMAIL PROTECTED]> writes:
I think what people are trying to suggest is an 'initialization
phase' in the IO monad, which takes place "before" the pure
functions are defined.
If it was done before, what could you use to specify i
On Tuesday 12 October 2004 21:25, Adrian Hey wrote:
> I've never really understood what people mean by things being
> "inside" and "outside" the IO monad :-(
Inside the IO monad means "correctly sequenced together with other IO
operations which are inside the IO monad". It's called "inside" since
On Tuesday 12 Oct 2004 6:28 pm, Jules Bean wrote:
> On 12 Oct 2004, at 14:08, Adrian Hey wrote:
> >> x <- someAction
> >> y <- someAction(x)
> >
> > I would say keep things as they currently are with the unsafePerformIO
> > solution, I.E. Order unspecified, the action that creates a particular
> >
Jules Bean <[EMAIL PROTECTED]> writes:
> I think what people are trying to suggest is an 'initialization
> phase' in the IO monad, which takes place "before" the pure
> functions are defined.
If it was done before, what could you use to specify initial value of
such a variable? Only literals? Con
On 12 Oct 2004, at 14:08, Adrian Hey wrote:
x <- someAction
y <- someAction(x)
I would say keep things as they currently are with the unsafePerformIO
solution, I.E. Order unspecified, the action that creates a particular
top level thing is executed only once, when the value of thing is
demanded (pe
On Tuesday 12 Oct 2004 1:44 pm, Vincenzo Ciancia wrote:
> On Tuesday 12 October 2004 12:23, Adrian Hey wrote:
> > I don't know what more
> > general-purpose extension you have in mind, but couldn't you just
> > borrow from do syntax at the top level
>
> I think that the problem is with the order o
On Tuesday 12 October 2004 12:23, Adrian Hey wrote:
> I don't know what more
> general-purpose extension you have in mind, but couldn't you just
> borrow from do syntax at the top level
I think that the problem is with the order of execution of these
bindings. For example ghci supports top-level
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I'd like to add that while the implementation might be a little unsafe,
> there's no problem in principle with the semantics of top-level IORefs.
> We could add such a thing as a GHC extension, but it would be nice if it
> were an instance of a more gen
On Monday 11 Oct 2004 4:03 pm, Simon Marlow wrote:
> On 08 October 2004 19:18, Sven Panne wrote:
> > c) Give up any hope of clean semantics and simply use a common hack
> > like:
> >
> >{-# NOINLINE myGlobalVar #-}
> >myGlobalVar :: IORef Int
> >myGlobalVar = unsafePerformIO
On 08 October 2004 19:18, Sven Panne wrote:
> Jules Bean wrote:
>> [...] Unfortunately, it's not going to work. It's not going to work
>> because some of the procedures take callbacks, and the callbacks are
>> values of type IO (). I can see two solutions to this:
>>
>> a) revert to using an IORe
Jules Bean wrote:
[...] Unfortunately, it's not going to work. It's not going to work because
some of the procedures take callbacks, and the callbacks are values of
type IO (). I can see two solutions to this:
a) revert to using an IORef [...]
b) write the callbacks as values of type StateT Env
Hi,
I've been playing with some haskell bindings which basically bind C
procedures in the IO monad. To write 'interesting' programs, you often
need to manage your own state in addition to the implicit IO state.
I have been allocating references with newIORef and then passing them
around all my
31 matches
Mail list logo
