On Saturday 13 Nov 2004 10:39 am, Keean Schupke wrote:
> Actually, I Think I'm wrong - I think its not even safe if you cannot
> export the '<-' def. If any functions which use it are exported you are
> in the same situation. I cannot say the kind of code in the example I
> gave is good, can you? I
Actually, I Think I'm wrong - I think its not even safe if you cannot
export the '<-' def. If any functions which use it are exported you are
in the same situation. I cannot say the kind of code in the example I
gave is good, can you? Infact the availability of these top level IO
actions seems
Well lets say:
userInit <- oneShot realInit
where realInit defines an MVar used for state storage that is used in
module A to implement
an accumulator. Now module B does some maths using the accumulator, and
module C does
some maths using the accumulator. If Main uses functions defined in
On Saturday 13 Nov 2004 9:15 am, Keean Schupke wrote:
> >I'm not sure I understand what problem you think there is. Are the inits
> >you're talking about module inits? If so, I don't think there's a problem,
> >for several reasons.
> >
> >The idea under discussion is that a top level (x <- newThing
I'm not sure I understand what problem you think there is. Are the inits
you're talking about module inits? If so, I don't think there's a problem,
for several reasons.
The idea under discussion is that a top level (x <- newThing) should
be lazy, (no action at all occurs until value of x is demand
On Friday 12 Nov 2004 5:42 pm, Judah Jacobson wrote:
> On Fri, 12 Nov 2004 14:53:33 +, Adrian Hey <[EMAIL PROTECTED]> wrote:
> > On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
> > > On the other hand, these are perfectly safe:
> > >
> > > once' :: IO a -> IO (IO a)
> > > once
On Friday 12 Nov 2004 3:20 pm, Keean Schupke wrote:
> Adrian Hey wrote:
> >The latter is probably true, in a strict technical sense. But I can't
> >see a way to live without them and keep modularity. In any case,
> >I don't think there's any reason to force programmers "wear the hair
> >shirt" in t
On Fri, 12 Nov 2004 14:53:33 +, Adrian Hey <[EMAIL PROTECTED]> wrote:
> On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
>
>
> > On the other hand, these are perfectly safe:
> >
> > once' :: IO a -> IO (IO a)
> > oncePerString :: String -> IO a -> IO a
> > oncePerType :
This still has a problem. Lets say B implements some useful function that
relies on A. Now also C implements some different useful function and also
relies on A in its implementation. If there is only one A.a then using
both B
and C features in the same code will potentally break both B and C. The
Should values really depend on the order of includes? Even if you limit
things to just
newChan in top level '<-' you still don't know if A.a in B the same A.a
in C. Perhaps it
is enough to say A.a only exists once no matter how many times it is
directly or
indirectly imported?
This strikes me
Adrian Hey wrote:
The latter is probably true, in a strict technical sense. But I can't
see a way to live without them and keep modularity. In any case,
I don't think there's any reason to force programmers "wear the hair
shirt" in this respect (other than dogma and superstitious fear about
the evi
On Thursday 11 Nov 2004 12:27 pm, Ben Rudiak-Gould wrote:
> On the other hand, these are perfectly safe:
>
> once' :: IO a -> IO (IO a)
> oncePerString :: String -> IO a -> IO a
> oncePerType :: Typeable a => IO a -> IO a
>
> once' seems virtually useless unless you have top-level <-,
> So you say (and I do agree). But how can I *observe* that they are the same?
Well, not with a single program run (obviously). But it is the case
that for any program P and input sequence X (i.e., keys
pressed):
running P with X
and
running {foo = getChar; P'} with X (where P' is P with all
At 16:07 11/11/04 +, Keith Wansbrough wrote:
Graham Klyne wrote:
> At 12:27 11/11/04 +, Ben Rudiak-Gould wrote:
[..]
> >going to be safe, because it's just not the case that
> >
> >x = once (newIORef ())
> >y = x
> >
> >has the same intended meaning as
> >
> >x = once (newIORef
Actually, I don't see anything wrong on the face of it with
oncePerType :: Typeable a => IO a -> IO a
since the only instances of Typeable are monomorphic. Indeed, the
implementation seems pretty straightforward: store the results of
already-run computations as Dynamic values in a global dictiona
On Thu, 11 Nov 2004 20:14:24 +, Keean Schupke
<[EMAIL PROTECTED]> wrote:
> I think you are right... The only safe operation I can see for a
> one-time init
> is type IO (). All results have to be returned via side effects. Hence with
> my named-MVar proposal the first execution of the init func
I think you are right... The only safe operation I can see for a
one-time init
is type IO (). All results have to be returned via side effects. Hence with
my named-MVar proposal the first execution of the init function initialises
certain named-MVars, and subsequent executions do nothing at all. T
On Thu, 11 Nov 2004 12:27:17 +, Ben Rudiak-Gould
<[EMAIL PROTECTED]> wrote:
>
> On the other hand, these are perfectly safe:
>
> once' :: IO a -> IO (IO a)
> oncePerString :: String -> IO a -> IO a
> oncePerType :: Typeable a => IO a -> IO a
>
> once' seems virtually useless un
Graham Klyne wrote:
> At 12:27 11/11/04 +, Ben Rudiak-Gould wrote:
[..]
> >going to be safe, because it's just not the case that
> >
> >x = once (newIORef ())
> >y = x
> >
> >has the same intended meaning as
> >
> >x = once (newIORef ())
> >y = once (newIORef ())
> >
> >No amou
On Thu, 11 Nov 2004 09:16:04 +, Adrian Hey <[EMAIL PROTECTED]> wrote:
>
> That's the trouble with unsafePerformIO. Haskell is supposed to be a
> purely functional language and the compiler will assume all functions
> are pure. As soon as you use unsafePerformIO to create something that
> isn't
At 12:27 11/11/04 +, Ben Rudiak-Gould wrote:
Graham Klyne wrote:
Wouldn't it be easier to simply define "once" as a common Haskell library
function?
Depends on the type and the expected semantics. As Adrian Hey already
pointed out, (once :: IO a -> IO a) with the obvious semantics is never
g
Graham Klyne wrote:
Wouldn't it be easier to simply define "once" as a common Haskell
library function?
Depends on the type and the expected semantics. As Adrian Hey already
pointed out, (once :: IO a -> IO a) with the obvious semantics is never
going to be safe, because it's just not the case t
At 11:31 11/11/04 +, Keean Schupke wrote:
Wouldn't it be easier to simply define "once" as a common Haskell library
function?
Erm, it is a library function (I provided the NamedSem library as an
attachment)... Are you suggesting it would be nice to be able to do this
without talking to the O
Graham Klyne wrote:
Keean,
As far as I can tell, both your solutions to the "one-shot" problem
require that:
(a) the expression to be one-shotted is in the IO monad. That seems
reasonable, since why else does one care (semantically speaking)?
(b) they depend on the host operating system platfo
Keean,
As far as I can tell, both your solutions to the "one-shot" problem require
that:
(a) the expression to be one-shotted is in the IO monad. That seems
reasonable, since why else does one care (semantically speaking)?
(b) they depend on the host operating system platform (semaphores, proc
On Thursday 11 Nov 2004 6:36 am, Judah Jacobson wrote:
> AFAIKS, the definition of "once" that I gave uses unsafePerformIO in a
> perfectly sound manner; namely, the creation of a top-level MVar. It
> only becomes unsafe if certain "optimizations" are performed; but
> then, that's also true for th
Hi,
Here's another completely safe (and simpler way) to limit
a computation to only happen once:
once' :: IO () -> IO ()
once' f = do
k <- getProcessID
a <- getEnv (showString "MyApp.Main" $ show k)
case a of
Just _ -> return ()
_ -> do
f
Adrian Hey wrote:
Suppose I had..
myOtherRef :: IO (IORef Char)
myOtherRef = once (newIORef 'a')
There's nothing to stop the compiler doing CSE and producing, in effect..
commonRef :: IO (IORef Char)
commonRef = once (newIORef 'a')
.. followed by substitution of all occurrences of myRef and myOther
OK, I'll play again..
On Wednesday 10 Nov 2004 4:39 pm, Judah Jacobson wrote:
> What about the following? It does use unsafePerformIO, but only to
> wrap newMVar in this
> specific case.
>
> once :: Typeable a => IO a -> IO a
> once m = let {-# NOINLINE r #-}
> r = unsafePerformIO (n
What about the following? It does use unsafePerformIO, but only to
wrap newMVar in this
specific case.
once :: Typeable a => IO a -> IO a
once m = let {-# NOINLINE r #-}
r = unsafePerformIO (newMVar Nothing)
in do
y <- takeMVar r
x <- case y of
I have written a small library for supporting one-shot without using
unsfePerformIO...
The library uses SYSV semaphores under linux to make sure the functional
argument of
"once" is only ever run once. It uses the ProcessID as the key for the
semaphore, so will
even enforce the once-only propert
On 09 November 2004 11:54, Graham Klyne wrote:
> I've not been following the Global variables debate too closely, it
> seeming to have something of a religious wars flavour, but I noticed
> that an example being proposed was how to achieve a "one shot"
> execution. Here's something I did when wor
I've not been following the Global variables debate too closely, it seeming
to have something of a religious wars flavour, but I noticed that an
example being proposed was how to achieve a "one shot" execution. Here's
something I did when working on modifications to the HaXML parser:
[[
-- Me
33 matches
Mail list logo