On Wed, Mar 01, 2006 at 11:53:42AM +, Simon Marlow wrote:
something along these lines is likely to be quite straightforward to
implement, won't require any changes to the type system, and gives you
a useful form of implicit parameters without any of the drawbacks.
The main difference
Hello Lauri,
Thursday, March 2, 2006, 3:25:31 PM, you wrote:
LA Now, I wonder whether we really really really need to track implicit
LA parameters in the type system. After all, exceptions, too, introduce a
there is also another way - allow partial function signatures
--
Best regards,
Bulat
Ashley Yakeley wrote:
Simon Marlow wrote:
Simon I have discussed doing some form of thread-local state, which
covers many uses of implicit parameters and is much preferable IMO.
Thread-local state doesn't change your types, and it doesn't require
passing any extra parameters at runtime. It
Ashley Yakeley wrote:
Ben Rudiak-Gould wrote:
I'd advise against using implicit parameters, because (as you've seen)
it's hard to reason about when they'll get passed to functions.
And Johannes Waldmann wrote:
Implicit parameters are *evil*. They seem to simplify programs
but they make
Hello Simon,
Tuesday, February 28, 2006, 5:40:35 PM, you wrote:
SM Simon I have discussed doing some form of thread-local state, which
this means new RTS primitives, like that used in IORef implementation?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
Simon Marlow wrote:
Simon I have discussed doing some form of thread-local state, which
covers many uses of implicit parameters and is much preferable IMO.
Thread-local state doesn't change your types, and it doesn't require
passing any extra parameters at runtime. It works perfectly well
| Sent: 19 January 2005 14:42
| Unbound implicit parameter (?global_counter::IORef a)
| arising from use of `get_unique' at Test.hs:17:13-22
|
| Is this a bug? Is there some reason why this is not possible? (and if
it
| is not possible
| shouldn't the documentation be changed to reflect
In article [EMAIL PROTECTED],
Ben Rudiak-Gould [EMAIL PROTECTED] wrote:
Another extension I proposed is that the name of an implicit return
value can include type parameters: thus %foo Int and %foo Char would be
treated as though they had different names.
This bit doesn't seem very
On Thu, 29 Jan 2004, Ashley Yakeley wrote:
Ben Rudiak-Gould [EMAIL PROTECTED] wrote:
Another extension I proposed is that the name of an implicit return
value can include type parameters: thus %foo Int and %foo Char would be
treated as though they had different names.
This bit
