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
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
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
(indexing with TypeRep)
This is yet another incidence where Robert Will's ByMaps would be very useful
In fact GHC at least *already* generates a unique integer for each TypeRep.
A good idea, since it means comparisons can be done in unit time.
Thus indexing can be done trivially using this
Benjamin wrote (snipped):
Typeable would be completely safe if the only way to declare instances
would be to derive them, but this is only practical if it can be done
from anywhere outside the data type definition.
Unfortunately this would also outlaw some legitimate uses of Typeable.
In
[EMAIL PROTECTED] wrote:
(initialising by wish)
This indeed can't be proved central+affine, because it isn't. So instead,
choose one of the following:
1 (Good) Indirection:
declare gc - newIORef None; so that gc is a global variable holding a
(Maybe GraphicsContext). Initialise the
This is funny. When I got no immediate reaction from you, I started
implementing it myself. I ended up with something similar. It has less
features but is also a lot simpler. This is the interface:
initGlobal :: Typeable a = a - IO ()
getGlobal :: Typeable a = IO a
Your implementation is
Ian Stark wrote (snipped):
Way back in this thread, Koen Claessen mentioned the idea of a commutative
version of the IO monad for handling things with identity. That doesn't quite
do it, but I have a refinement that might. The thing is to focus on IO
computations that are:
a) central --
Marcin wrote (snipped):
I think global variables are a lot less evil if they behave as if they
were dynamically scoped, like Lisp special variables.
That is, there is a construct which gives the variable a new mutable
binding visible in the given IO action. It's used more often than
Benjamin Franksen wrote (snipped):
Doesn't that run contrary to Adrian Hey's oneShot example/requirement?
Remind me again what Adrian Hey's oneShot example/requirement is ...
Well, that's indeed one major problems with global variables. Sure, you can
try to solve it with multiple dictionaries,
Christian Maeder wrote (snipped)
btw, now 127:
roman=(!5);n!a|n1=|n=t=s!!(a+1):(n-t)!a|c=t=s!!(2*d):c!a|10=n!(a-1)where
d=a`div`2;s=ivxlcdm;c=10^d+n;t=5^(d+1)*2^(a-d)
This is amazing! When I posted my first attempt of 181 characters I thought it
might be minimal.
George Russell wrote:
The following declaration for a function for converting positive
integers to Roman numerals is 181 characters long.
Is there a shorter one?
Yes, thanks to various contributors to this list, the shortest is now
148 characters!!
roman=f 0;f a n|n1=|n=t!!a=s!!a:f a(n-t!!a)|n+t
13 matches
Mail list logo
