On Wednesday 24 Nov 2004 11:50 am, Keean Schupke wrote:
There is no problem getting multiple copies of the channels... I take it
you are not familiar with the internals of OSs
IME there is no uniformity wrt OS internals, and I can't claim to be
familiar with them all. It's also fairly safe to
On Tuesday 23 Nov 2004 9:29 am, Keean Schupke wrote:
Is this a joke?
No.
Seriously if you writing the OS in haskell this is trivial,
you fork a thread using forkIO at system boot to maintain the driver,
all 'processes' communicate to the thread using channels, the thread
maintains local
On Tuesday 23 Nov 2004 9:39 am, Lennart Augustsson wrote:
I find it hard to argue these things in the abstract. Could you
post us a (simplified) signature for a module where you are
using top level variables? Maybe that way I can be convinced
that you need them. Or vice versa. :)
Nope,
Adrian Hey wrote:
On Tuesday 23 Nov 2004 9:39 am, Lennart Augustsson wrote:
I find it hard to argue these things in the abstract. Could you
post us a (simplified) signature for a module where you are
using top level variables? Maybe that way I can be convinced
that you need them. Or vice versa.
Adrian Hey wrote:
On Tuesday 23 Nov 2004 9:29 am, Keean Schupke wrote:
myDriver :: (Chan in,Chan out) - State - IO State
myDriver (in,out) state = do
-- read commands from in
-- process commands
-- reply on out
myDriver (in,out) new_state
How does this solve the
There is no problem getting multiple copies of the channels... I take it
you are not familiar with the internals of OSs (I have written a small
OS myself, complete with real device drivers)... The OS is started at
boot, it initialises its own state, then it forks the device drivers, then
it forks
On Monday 22 Nov 2004 6:27 pm, Lennart Augustsson wrote:
Personally, I can't believe I hear people arguing for global variables.
Oh dear, here we go again. I repeat, AFAIK nobody who wants a solution to
this problem is advocating the use of global variables, though it's
true that the proposal
On Monday 22 Nov 2004 11:26 am, Keean Schupke wrote:
Adrian Hey wrote:
Just repeating this again and again doesn't make it any more true.
Ditto... I for one think the best solution is to use the language as
intended and pass the values as function arguments.
I guess you mean the usual handle
On Monday 22 Nov 2004 4:03 pm, Benjamin Franksen wrote:
This is getting ridiculous. At least two workable alternatives have been
presented:
- C wrapper (especially if your library is doing FFI anyway)
- OS named semaphores
Neither of these alternatives is a workable general solution.
There
Is this a joke? Seriously if you writing the OS in haskell this is trivial,
you fork a thread using forkIO at system boot to maintain the driver,
all 'processes' communicate to the thread using channels, the thread
maintains local state (an IORef, or just a peramiter used recursively)
myDriver
Adrian Hey wrote:
As for openDevice, if a device should only allow a single open I would
assume this is part of the device driver in the operating system?
(I know this is shifting blame. But I think it shifts it to where it
belongs. In the OS there will be an open flag per device.)
IOW there is
Adrian Hey wrote:
I guess you mean the usual handle based approach, but this makes no
sense at all for a Haskell interface to some *unique* stateful resource
(eg. a piece of raw hardware or badly designed C library). The handle
is a completely redundant argument to all interface functions (there's
On Tuesday 23 November 2004 10:39, Keean Schupke wrote:
Adrian Hey wrote:
This is one situation, but certainly not the only possible one. You have
the same problem with interfacing to any unique stateful resource (or
even if you have a multiple but finite supply of these resources).
No you
On Tuesday 23 November 2004 09:10, Adrian Hey wrote:
On Monday 22 Nov 2004 6:27 pm, Lennart Augustsson wrote:
Personally, I can't believe I hear people arguing for global variables.
Oh dear, here we go again. I repeat, AFAIK nobody who wants a solution to
this problem is advocating the use
Okay - but then you can keep state in haskell by using a driver thread
and channels like in the example I posted. I guess I should have said
it is best practice to check the real state rather than a (possibly wrong)
copy.
Keean.
Benjamin Franksen wrote:
On Tuesday 23 November 2004 10:39, Keean
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
But - why would you want to use a pure C function. The chances of any useful
C library function being pure are slim - and the performance of GHC in some
of the benchmarks shows that there is hardly any speed
I think this is a useful debate, because it touches on how Haskell meets
real-world programming needs, so I shall continue in that spirit...
At 22:22 22/11/04 +, Keean Schupke wrote:
Obviously without knowing the details I am speculating, but would it not
be possible
to do a first pass of
Off topic, but interesting, Someone else keeps quoting this at me... I
prefer Knuth - paraphrased as I cant remember the quote - The best
software projects are the ones where the source code has been lost about
half way through the development and started from scratch.
The point is programmers
Keean Schupke wrote:
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
But - why would you want to use a pure C function.
Because it already exists? E.g. most BLAS/LAPACK functions are pure;
should they be re-written in Haskell?
[Yes, I know that
Keean Schupke wrote:
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
A C function might have no observable side effects, even if it operates
destructively over its own private data structures. It mightn't be too
hard to establish a sound test for this sort
Have you looked at Linear Aliasing, the type system used for TAL (typed
assembly
language)... one would assume that if a C compiler which compiles to TAL
were
produces, then you could proove purity?
Keean.
Conor McBride wrote:
Keean Schupke wrote:
Can a C function be pure? I guess it can... The
Glynn Clements wrote:
I thought these libraries did have some global state, like choosing
which solver is used... In which case treating them as pure could
be dangerous...
Keean.
Keean Schupke wrote:
Can a C function be pure? I guess it can... The trouble is you cannot
proove its
pure?
But
On Tuesday 23 November 2004 10:03, you wrote:
But - why would you want to use a pure C function. The chances of any
useful C library function being pure are slim - and the performance of GHC
in some of the benchmarks shows that there is hardly any speed advantage
The typical case (for me) is a
On Mon, Nov 22, 2004 at 08:32:33PM +, Graham Klyne wrote:
[Switching to Haskell-cafe]
At 11:26 22/11/04 +, you wrote:
I would ask an alternative question - is it possible to live without
unsafePerformIO? I have never needed to use it!
There are plenty of non-IO reasons to use
David Roundy wrote:
There are plenty of non-IO reasons to use unsafePerformIO, for which it is
essential. If you want to write haskell code that uses a pointer
(allocated possibly via an FFI C routine), it has to be in the IO monad.
If you know that this pointer doesn't access memory that'll be
On Tue, Nov 23, 2004 at 01:51:24PM +, Keean Schupke wrote:
David Roundy wrote:
There are plenty of non-IO reasons to use unsafePerformIO, for which it is
essential. If you want to write haskell code that uses a pointer
(allocated possibly via an FFI C routine), it has to be in the IO
At 10:02 23/11/04 +, you wrote:
Off topic, but interesting,
Sure... that's why its in 'cafe, right?
Someone else keeps quoting this at me... I prefer Knuth - paraphrased as I
cant remember the quote - The best software projects are the ones where
the source code has been lost about half way
On Friday 19 Nov 2004 2:27 pm, Benjamin Franksen wrote:
Implicit parameters are evil, agreed. Their deficiencies should be added
as a warning to the docs (with many exclamation marks).
Well I dunno. Maybe whatever's currently wrong with them can be fixed up.
But I can't say they're something
Adrian Hey wrote:
Just repeating this again and again doesn't make it any more true.
Ditto... I for one think the best solution is to use the language as
intended and pass the values as function arguments. As pointed out
on this list - the only possible situation where you cannot do this is
when
On Mon, Nov 22, 2004 at 07:27:44PM +0100, Lennart Augustsson wrote:
[snip]
I admit there are proper uses of global variables, but they are very
rare. You have not convinced me you have one.
-- Lennart
It's with some trepidation I bring a problem as a total newbie, but I've
been
On Mon, 2004-11-22 at 23:34, John Velman wrote:
In a nutshell:
I want to use the old value of a tag to compute the new value, in a
callback,
I want to access the tag from other callbacks, and
I want to the value to a mutable list from within the callback.
I'd
[Switching to Haskell-cafe]
At 11:26 22/11/04 +, you wrote:
I would ask an alternative question - is it possible to live without
unsafePerformIO? I have never needed to use it!
I have used it once, with reservations, but at the time I didn't have the
time/energy to find a better solution.
Obviously without knowing the details I am speculating, but would it not
be possible
to do a first pass of the XML and build a list of files to read (a pure
function) this returns
its result to the IO monad where the files are read and concatenated
together, and passed
to a second (pure
On Monday 22 November 2004 23:22, Keean Schupke wrote:
It seems to me that as unsafePerformIO is not in the standard and only
implemented on some
compilers/interpreters, that you limit the portability of code by using
it, and that it is best avoided. Also as any safe use of unsafePerformIO
34 matches
Mail list logo
