Simon PJ wrote (snipped):
This unfortunate observabilty of an ordering (or hash value) that is
needed only for efficient finite maps, is very annoying. I wish I knew
a way round it. As it is we can pick
a) expose Ord/Hash, but have unpredictable results
b) not have Ord/Hash, but have
Hello George,
I've been looking at your global variables library. As far as I can tell
it seems to be aimed at solving a rather different problem from that the
top-level - bindings are aimed at. So I don't think you can really
compare them. One is not a substitute for the other.
In particular,
The trouble is that *any* function can now deliver unpredictable
results. Can I rely on the fact that
foo :: Int - Int
will always give the same answer given the same input. Not any more.
I think the strongest argument here is that it's like a more benign
version of unsafePerformIO,
Adrian Hey wrote:
Also, we don't want different threads to have their own versions of
these. They are for use in situations where you need to represent
state associated with a genuinely unique resource (eg top level
stateful C library or hardware IO device)
So in such situations it's both
Keean Schupke wrote:
Look at how Linux scans the hardware at boot time and initialises
a driver for each device it finds... that means that each driver is
parameterised
by the IO address of the device, and can be initialised multiple times.
When an
OS boots it runs an initialisation routine (the
Simon Peyton-Jones wrote:
The trouble is that *any* function can now deliver unpredictable
results. Can I rely on the fact that
foo :: Int - Int
will always give the same answer given the same input. Not any more.
Yes, I see what you mean.
I think the strongest argument here is that it's
George Russell wrote:
Simon Peyton-Jones wrote:
The trouble is that *any* function can now deliver unpredictable
results. Can I rely on the fact that
foo :: Int - Int
will always give the same answer given the same input. Not any more.
Yes, I see what you mean.
I think the strongest
On Mon, 29 Nov 2004, Simon Peyton-Jones wrote:
This unfortunate observabilty of an ordering (or hash value) that is
needed only for efficient finite maps, is very annoying. I wish I knew
a way round it. As it is we can pick
a) expose Ord/Hash, but have unpredictable results
b)
On Tuesday 30 Nov 2004 11:21 am, Keean Schupke wrote:
I want Haskell to be the operating system - how can I do
this if I cannot create new process contexts. Also how can I
deal with multiple pieces of hardware that are unique?
The problem with your proposal is that resources are finite, not
Adrian Hey wrote (snipped):
I've been looking at your global variables library.
Thanks.
In particular, the purpose of top level - bindings IMO is *not* to
provide global variables (though they could be abused this way).
If you consider the example..
userInit - oneShot realInit
..the top level
(me)
I suggest you implement
hashTypeable :: Typeable - IO Int32
Lennart wrote (snipped)
And/or
mkHashTypeable :: IO (Typeable - Int32)
Although this is OK, a general hash function might well need
to return IO HashKey.
A while back, before Data.Unique, I implemented a Unique module
with
Adrian Hey wrote:
Sorry Keean, but throughout this entire thread I have had the feeling
that you are determined to misunderstand and misrepresent just about
everything I have written.
Well I think I understand it quite well - of course I may be being stupid...
that is always a possibility.
You
Hi All,
After some weeks of experimenting and digging around, I understand that
functions cannot be compared for equality. Thanks to Bjorn Lisper for
pointing this out. I basically understand (?) the underlying mathematical
issue, which is that functions in general may have infinite domains and
Adam Zachary Wyner wrote:
Question -- is this all there is to the issue, or is there something more?
Apologies in advance for not understanding the math better here.
You can compare functions in a pointwise fashion,
which does not work (other than approximatively) for infinite domains.
This is the
On 30 Nov 2004, at 13:22, Adam Zachary Wyner wrote:
Question -- is this all there is to the issue, or is there something
more?
Apologies in advance for not understanding the math better here.
From the point of view of a programmer, that's all there is to it:
there is no way of proving two
Hi, all,
I'm new to the Cafe, but not to Haskell (experimented with it on and
off on a small scale over the last 5 or 6 years and enjoy the language
quite a lot) and had more of a political question and wanted to see
what people thought:
Has anyone tried presenting the language to the average
On Tue, 30 Nov 2004, GoldPython wrote:
Hi, all,
I'm new to the Cafe, but not to Haskell (experimented with it on and
off on a small scale over the last 5 or 6 years and enjoy the language
quite a lot) and had more of a political question and wanted to see
what people thought:
Has
On Tuesday 30 Nov 2004 12:53 pm, George Russell wrote:
Adrian Hey wrote (snipped):
They are for use in situations where you need to represent
state associated with a genuinely unique resource (eg top level
stateful C library or hardware IO device).
In my experience this is only true
Adrian Hey wrote:
The issue is *modularity*. Without top level TWIs there are certain
safety guarantees that I cannot make from within my module. Instead
I have to beg for safe use from outside my module. Begging a
hypothetical operating system doesn't really help much.
And I am arguing that
---BeginMessage---
Adrian Hey wrote:
Keean and Lennart are just hiding the problem in a hypothetical
operating system which is simply assumed to be correct (it just
doesn't do any of the dangerous things that might otherwise be done).
Well, if think I'm not reading your postings then I think I
GoldPython [EMAIL PROTECTED] writes:
Has anyone tried presenting the language to the average rank and file
programming community? If so, was it successful? If not, is there
interest in doing so?
The #haskell irc channel on irc.freenode.net is composed of many different
flavors of programmer,
| I think it would be nice to summarise the current state of play. This
really
| needs to be a WiKi.
Thanks for the summary, George.
| 2. Which if either of the proposals would the gods responsible for
implementing
| Haskell compilers favour?
Rather than remain completely silent on this
On Tue, Nov 30, 2004 at 04:57:27PM +0100, Shae Matijs Erisson wrote:
The #haskell irc channel on irc.freenode.net is composed of many different
flavors of programmer, from self-educated 16 year olds on up to post doctoral
students studying functional programming.
I'm a self-educated,
Hello,
I have this line:
type CPResult a = MonadError CPError m = m a
GHC (with various command-line options I'm already using) compiles this
fine.
hugs, with -98 +o, complains:
Syntax error in input (unexpected `=')
How do I make this work both places?
Thanks for response; unfortunately my problem was a bit deeper.
Note to self: try to verify all code snippets before posting ;-)
The problem is that code on line 4 is useless.
If one of the arguments a or b is Nothing, computation will just return
Nothing and will not bother to execute lines
On Tue, Nov 30, 2004 at 06:36:46PM +, Pavel Zolnikov wrote:
The problem is that code on line 4 is useless.
If one of the arguments a or b is Nothing, computation will just return
Nothing and will not bother to execute lines 4-5:
1 foo a b = do
2 output before
3 let r =
You are absolutely right! I missed that let.
And it does work, thanks.
On the other hand it is still not what I intended, so I decided
not to use Monads in this particular case. I wanted to represent
values that can fail and that have complete history of errors.
So that if I calculate
c =
On Tuesday 30 November 2004 11:41, Adrian Hey wrote:
In particular, the purpose of top level - bindings IMO is *not* to
provide global variables (though they could be abused this way).
...
If you consider the example..
userInit - oneShot realInit
..the top level MVar created is not
Keean Schupke [EMAIL PROTECTED] writes:
I disagee - Allowing unique state is a mistake in my opinion.
I want Haskell to be the operating system - how can I do
this if I cannot create new process contexts.
Why does it matter if you can't compile code for new programs at
runtime, to become a
On 30 Nov 2004, at 20:55, Pavel Zolnikov wrote:
Now I realize that as long as I am using liftM2 it is not possible
to have history of errors from a and b - only form a. And as I moved
to custom lift functions I realized I didnt need monads in the
first place.
It's not liftM2 that's the problem,
Jules Bean wrote:
However, your problem *does* have a natural underlying monad, if you
care to use it.
I may be confused, but I don't think it does. It seems like the OP wants
a type like
data Perhaps a = Success a | Failure [Error]
and semantics like
liftM2 (+) (Failure [error1])
Ben Rudiak-Gould [EMAIL PROTECTED] writes:
I may be confused, but I don't think it does. It seems like the OP
wants a type like
data Perhaps a = Success a | Failure [Error]
When writing a compiler, it makes sense to collect errors as by the
writer monad, and not abort anything -
On Tue, 2004-11-30 at 13:52 +, Jules Bean wrote:
In the same sense, you could try
(map f [1..]) == (map g [1..])
and it will return False quickly if they are different, but it will run
forever if they are the same.
For some very generous definition of quickly :)
Bernie.
On 1 Dec 2004, at 01:06, Bernard Pope wrote:
On Tue, 2004-11-30 at 13:52 +, Jules Bean wrote:
In the same sense, you could try
(map f [1..]) == (map g [1..])
and it will return False quickly if they are different, but it will
run
forever if they are the same.
For some very generous definition
Woops... scratch my stupitity... we could of course discover the test
to be false on an extremely large integer.
Bob
--
God is real... Unless you define it as an integer.
On 1 Dec 2004, at 01:19, Thomas Davie wrote:
On 1 Dec 2004, at 01:06, Bernard Pope wrote:
On Tue, 2004-11-30 at 13:52 +,
Adam Zachary Wyner wrote:
Hi All,
After some weeks of experimenting and digging around, I understand that
functions cannot be compared for equality. Thanks to Bjorn Lisper for
pointing this out. I basically understand (?) the underlying mathematical
issue, which is that functions in general may
Jules Bean wrote:
From the point of view of a programmer, that's all there is to it:
there is no way of proving two functions are the same except by
exhaustively checking every input.
That is too pessimistic, I'm afraid. There is also an intensional
equality. Granted, it can be sound but
37 matches
Mail list logo
