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
I don't know if HTk is still maintained.
Yes it is! It's time I put some more binary bundles up though.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
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
Thanks to the encouraging post
http://www.haskell.org//pipermail/haskell/2004-November/014748.html
from Benjamin Franksen, I have implemented
my proposal which allows the user to define new global variables without
unsafePerformIO, NOINLINE and other such horrors.
George Russell wrote:
(3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
It uses unsafePerformIO which is very much an extension to Haskell. :)
-- Lennart
___
Haskell mailing list
Lennart Augustsson wrote:
George Russell wrote:
(3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
It uses unsafePerformIO which is very much an extension to Haskell. :)
I think by Haskell he means the common language currently
I wrote (snipped):
3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
Lennart Augustsson wrote (snipped):
It uses unsafePerformIO which is very much an extension to Haskell. :)
Ben Rudiak-Gould wrote (snipped):
I think by Haskell
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
On 2004-11-22, Benjamin Franksen [EMAIL PROTECTED] wrote:
On Monday 22 November 2004 09:38, Adrian Hey wrote:
You have yet to
explain how you propose to deal with stdout etc..
I see absolutely no reason why stdxxx must or should be top-level mutable
objects. They can and should be treated
Call for Papers - ICTAC05
INTERNATIONAL COLLOQUIUM ON
THEORETICAL ASPECTS OF COMPUTING
Hanoi, Vietnam - 17--21 October, 2005
http://www.iist.unu.edu/ictac05
=
BACKGROUND AND OBJECTIVES
ICTAC is an International Colloquium on Theoretical Aspects of
Computing founded by the
--
Apologies for multiple copies
--
CALL FOR PARTICIPATION
On Tuesday 23 November 2004 00:10, Aaron Denney wrote:
On 2004-11-22, Benjamin Franksen [EMAIL PROTECTED] wrote:
On Monday 22 November 2004 09:38, Adrian Hey wrote:
You have yet to
explain how you propose to deal with stdout etc..
I see absolutely no reason why stdxxx must or should be
Can I suggest that this thread, interesting as it is, might usefully migrate to
haskell-café. (Apart from anything else, there's another similar thread
running there, and it makes sense to keep together.) Posting a summary back to
the Haskell list, in due course, would be great.
Simon
|
Hi everyone,
I've been using Haskell for 1-2 months now, and feel fairly comfortable
with the language. However, my #1 gripe is the difficulty of working
with exceptions. I have two main complaints: difficulty of defining
custom exceptions, and difficulty of handling exceptions.
I've been
On 23 Nov 2004, at 11:53, George Russell wrote:
I wrote (snipped):
3) It needs no extensions to the Haskell language, and only fairly
standard hierarchical libraries like Data.IORef.
Lennart Augustsson wrote (snipped):
It uses unsafePerformIO which is very much an extension to Haskell.
:)
Ben
The other annoying thing is forcing it to run in the IO monad.
necessarily so, since Haskell has non-strict semantics
so it's not so clear when an exception is actually raised
(you might have left the block that textually contained the offending
expression , and the exception handler, a long
From: John Goerzen [mailto:[EMAIL PROTECTED]
My other choice is to use Dynamic for my
exceptions, but that makes it even more
difficult to catch and handle
Here's how I create custom exceptions; it doesn't seem onerous to me, but
then I have a high tolerance for some kinds of coding pain:
On Tue, Nov 23, 2004 at 04:30:21PM +, Keean Schupke wrote:
I am sure this discussion has happened before, but I think for pure
functions, returning Either Error Result is the way to go.
That's certainly possible, but extremely tedious.
One example: I've written an FTP client library. For
Bayley, Alistair writes:
data SqliteException = SqliteException Int String
deriving (Typeable)
catchSqlite :: IO a - (SqliteException - IO a) - IO a
catchSqlite = catchDyn
throwSqlite :: SqliteException - a
throwSqlite = throwDyn
I, too, think that's a good way to do it. And in
And in Haskell we have catch(Dyn), bracket, and finally.
Are these not enough?
We also have Control.Exception.try. :-)
Peter
Yes. Control.Exception.try is defined in terms of Control.Exception.catch:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control.Exception
I, too, had a gripe about this, and was pointed to an excellent paper that
explains all:
A Semantics for Imprecise Exceptions (1999)
Simon Peyton Jones, Alastair Reid, Tony Hoare, Simon Marlow, Fergus
Henderson
SIGPLAN Conference on Programming Language Design and Implementation
John Goerzen wrote:
myfunc :: String - Int
This does some sort of string parsing and returns an Int. Or it may
raise an exception if it couldn't parse the string. But it would do
that every time.
Now, let's say we have a non-IO catchJust. Of course, if we never need
the value, we never run
On 23 Nov 2004, at 15:51, John Goerzen wrote:
On Tue, Nov 23, 2004 at 04:30:21PM +, Keean Schupke wrote:
I am sure this discussion has happened before, but I think for pure
functions, returning Either Error Result is the way to go.
That's certainly possible, but extremely tedious.
It sounds to
On Tue, Nov 23, 2004 at 05:20:19PM +, Ben Rudiak-Gould wrote:
So what am I missing here?
myfunc might raise more than one exception. For example,
myfunc = error x + error y
Gotcha. That's the piece I was missing!
[ snip ]
those I catch. If each particular implementation were
On 2004-11-23, Benjamin Franksen [EMAIL PROTECTED] wrote:
On Tuesday 23 November 2004 00:10, Aaron Denney wrote:
On 2004-11-22, Benjamin Franksen [EMAIL PROTECTED] wrote:
On Monday 22 November 2004 09:38, Adrian Hey wrote:
You have yet to
explain how you propose to deal with stdout etc..
On 2004-11-23, Johannes Waldmann [EMAIL PROTECTED] wrote:
in the following example, the handler won't catch the exception
because of lazy evaluation. therefore, it's a different story
than with exceptions in ML, Python, whatever strict language.
main = do
xs - return [ 1, 2, error throw
John Goerzen wrote:
On Tue, Nov 23, 2004 at 05:20:19PM +, Ben Rudiak-Gould wrote:
In any case, mapException is pure, and it's good enough for most of
the cases where one might want to catch exceptions outside the IO monad.
Well, I'm maving trouble wrapping my head around how I could use it
John Goerzen wrote:
main = do
xs - return [ 1, 2, error throw ]
`catch` \ any - do
putStrLn caught
return [ 4, 5, 6 ]
print xs
When run, I get: Fail: throw
In any case, in the more general case, I don't see a problem with that.
I get an exception when
John Goerzen wrote:
Python can work that way, but also adds another feature:
try:
blah
moreblah
finally:
foo
And in Haskell we have catch(Dyn), bracket, and finally. Are these not
enough?
I hadn't been aware of finally. That does seem to help.
One of the things I like about exceptions
Ben Rudiak-Gould [EMAIL PROTECTED] writes:
The intended semantics is
/ Nothing if x is a set of exceptions
exceptionToMaybe x = | _|_ if x is _|_
\ Just xotherwise
What is
exceptionToMaybe (f 0 + error x)
where
f x = f
Marcin 'Qrczak' Kowalczyk wrote:
What is
exceptionToMaybe (f 0 + error x)
where
f x = f x
?
I guess that answers my question. :-)
-- Ben
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
G'day all.
Quoting George Russell [EMAIL PROTECTED]:
No. I mean by the Haskell language what is described in
the Haskell 98 Report. unsafePerformIO is not part of the language,
it is a value defined by one of the standard hierarchical libraries.
unsafePerformIO is part of the FFI addendum
On Mon, Nov 22, 2004 at 05:03:30PM +0100, Benjamin Franksen wrote:
You have been asked more than once to present a *real-life* example to
illustrate that
(a) global variables are necessary (and not just convenient),
(b) both above mentioned alternatives are indeed unworkable.
First of all,
On Tue, 23 Nov 2004 20:50:45 -0800, John Meacham [EMAIL PROTECTED] wrote:
On Mon, Nov 22, 2004 at 05:03:30PM +0100, Benjamin Franksen wrote:
You have been asked more than once to present a *real-life* example to
illustrate that
(a) global variables are necessary (and not just convenient),
On Tue, Nov 23, 2004 at 08:50:45PM -0800, John Meacham wrote:
Atom.hs from ginsu..
This is perhaps the best example, and an incredibly useful piece of code
for anyone struggling with space problems out there.
it provides
data Atom = ... (abstract)
instance Ord Atom
instance
[EMAIL PROTECTED] wrote:
No. I mean by the Haskell language what is described in
the Haskell 98 Report. unsafePerformIO is not part of the language,
it is a value defined by one of the standard hierarchical libraries.
unsafePerformIO is part of the FFI addendum to the H98 report. So I
think
How can I put this, it is a best efforts approach - it does its best
to run the
finalizers, even after a segmentation fault... however some of the
pointers may
be messed up... If the cleanup causes a segmentation fault (sometimes called
a double bus fault) then we have to abandon the cleanup.
I was wondering whether the method by which default types are chosen
for unresolved overloading could be made available to the programmer. It
seems
that if we consider the overlapping instances:
class x
instance Int
instance Float
instance x
x overlaps with Int and Float... I was
On 22 November 2004 17:28, Benjamin Franksen wrote:
I understand that there are situations where finalizers cannot be
guaranteed to run: First because of an unconditional termination
signal (SIGKILL), second because of circular dependencies resulting
in a deadlock.
I don't understand why
I'm afraid that hasn't helped. GHC appears to be looking for a package
'=DSP', but there's no indication why.
Could you give us enough instructions to be able to reproduce the
problem here, please? Including:
- full source code, or where to get it
- complete command lines
- platform, GHC
On 17 November 2004 14:01, Christian Maeder wrote:
[EMAIL PROTECTED] - uname -a
SunOS leo 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-280R
[EMAIL PROTECTED] - ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.2.1
[EMAIL PROTECTED] - gcc -v
Reading specs from
Simon Marlow wrote:
Note that the GC only starts the finaliser thread. The program can
still terminate before this thread has run to completion (this is one
reason why we say that finalisers don't always run before program
termination).
This sounds like a bug to me... surely you should wait
On Tuesday 23 November 2004 13:06, Simon Marlow wrote:
On 22 November 2004 17:28, Benjamin Franksen wrote:
I understand that there are situations where finalizers cannot be
guaranteed to run: First because of an unconditional termination
signal (SIGKILL), second because of circular
On 23 November 2004 13:46, Keean Schupke wrote:
Simon Marlow wrote:
Note that the GC only starts the finaliser thread. The program can
still terminate before this thread has run to completion (this is one
reason why we say that finalisers don't always run before program
termination).
Simon Marlow writes:
Note that the GC only starts the finaliser thread. The
program can still terminate before this thread has run
to completion [...]
If you want anything else, you can implement it.
How do I implement that particular feature? I don't see how
I could write a 'main'
On Wednesday 17 November 2004 15:06, Nils Anders Danielsson wrote:
On Wed, 17 Nov 2004, Benjamin Franksen wrote:
I want to use ghc as a script interpreter, using the '-e' option. The
problem is that I can't give the script any command line arguments,
because 'ghc -e' intepretes everything
On Wed, 24 Nov 2004, Benjamin Franksen wrote:
What about putting this thing on the Haskell Wiki?
Feel free to do so. I recently noted that some version of GHC (6.3?)
ships with a runghc program, so this problem will most likely disappear
soon, though.
On Tue, 2004-11-23 at 18:01 +0100, Peter Simons wrote:
Simon Marlow writes:
Note that the GC only starts the finaliser thread. The
program can still terminate before this thread has run
to completion [...]
If you want anything else, you can implement it.
How do I implement that
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
At 21:40 22/11/04 +0100, Ralf Laemmel wrote:
Instance selection and thereby overlapping resolution
is *independent* of constraints. It is defined to be purely
syntactical in terms of instance heads. See the HList paper
for some weird examples.
That explains it. Thanks!
#g
--
Ralf
Graham Klyne
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
To the list Haskell-cafe admin...
May I suggest that the maximum message length for postings to the
haskell-cafe list without moderation be raised from its current 5K
limit? It seems to me that a value of (say) 20K would reduce the
moderator's workload without obviously allowing too many
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
[I'm moving my response to the Haskell-cafe mailing list, as it seems more
appropriate for this kind of discussion.]
Your question seems to touch on the old chestnut of how to reconcile pure
functional programs with the inherently procedural aspects of I/O and state
management. Most of the
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
[we should really keep this on haskell-cafe because such lengthy discussions
are what the cafe is for]
On Tuesday 23 November 2004 10:26, Adrian Hey wrote:
On Monday 22 Nov 2004 4:03 pm, Benjamin Franksen wrote:
This is getting ridiculous. At least two workable alternatives have been
At 22:05 22/11/04 +, Keean Schupke wrote:
The trick here is to use a type to represent the constraint rather
than a class, if possible.
Keean
Hmmm, I'm not sure that I understand what you mean.
Considering my example (repeated below), is it that 'AtomicConcept' should
be an algebraic
The problem is that (cw c) overlaps with String. It will still ovarlap
if you use data decl.
it is the CW that needs to be a datatype. See Below:
Keean.
Graham Klyne wrote:
Hmmm, I'm not sure that I understand what you mean.
Considering my example (repeated below), is it that 'AtomicConcept'
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
At 16:16 23/11/04 +, Keean Schupke wrote:
The problem is that (cw c) overlaps with String. It will still ovarlap if
you use data decl.
it is the CW that needs to be a datatype. See Below:
Thanks. I've massaged that into something that compiles (copy below).
I think I see why this works, but
[for the third time moving this discussion to cafe]
On Tuesday 23 November 2004 20:20, Aaron Denney wrote:
[...about std file handles...]
They're wrappers around the integers 0, 1, and 2. The handles could
have been implemented to be the same, at each invocation. (I expect
they are in most
74 matches
Mail list logo
