Simon L Peyton Jones wrote:
The point is, if I *want* to have several behaviours in one run I can
always use this second technique. But Haskell as it now stands prevents
me from using the first, even when I *don't* want several behaviours in one
run. I'd be prepared to pay the pain if I
The point is, if I *want* to have several behaviours in one run I can always
use this second technique. But Haskell as it now stands prevents me from
using the first, even when I *don't* want several behaviours in one run.
I'd be prepared to pay the pain if I wanted the benefit. Since
timeStarted = performOnceBeforeMain (getCurrentTime)
Just like that one would do with unsafePerformIO, but with
safer semantics (hopefully) and blessed by Standard Haskell.
I see some serious problems:
a = (performOnceBeforeMain m1,performOnceBeforeMain m2)
In which order
I think Fergus's efficiency argument may be a red herring.
Here is an excerpt from a compiler I wrote recently:
data JvlArgs = JvlArgs {optNoLink :: Bool,
optVerbose :: Bool,
jvlClassNames :: [String]}
deriving Show
P.S. Is this list archived anywhere?
Not at the moment. But I'm planning on making messages available
on the web. I have all the posts since I started moderating the
list back in October, and I can probably get hold of stuff before
that.
Cheers,
David.
--
David J. King
Fergus,
Quite right. I used "error" because I was lazy.
In fact, the lazy evaluation of the arguments is also a red herring,
because the compiler is in fact strict in argv. (How else does it
know what to compile?) All the flag arguments must be scanned
in order to retrieve "jvlClassNames
Chris Dornan writes:
Surely, the argv global-constant proposal is cool. What is being proposed is
is a modest extension, namely introducing a constant that is initialised with a
copy of the command-line arguments. Cannot this sit along side the existing
proposal, with each mechanism
Fergus
| I would find Simon's arguments more convincing if he showed
| a convenient idiom that did things properly, rather than a
| convenient way to write broken programs.
|
| (Doing it properly is probably not too hard, but I'll leave it up to
| the proponents of this proposal to demonstrate
"variables won't, constants aren't" (sorry, don't remember the source)
The argv-problem and its proposed solutions:
1. fetch argv via the IO monad wherever it is needed
+ it works
- don't want to program everything in monadic style
2. fetch argv via the IO monad once and pass it
Lennart Augustsson writes:
Fergus Henderson wrote:
Sigbjorn Finne, you wrote:
I don't honestly see what having these handles as constant *gain* you,
so why then have them as such, if not having them constant gives you
extra expressiveness?
But, unless I'm missing something,
Fergus Henderson writes:
...
I'm still not entirely happy with the error handling, though.
As a general rule, I try to use `error' only for internal software
errors, not for error messages that can result from the user's
mistakes. (But perhaps that is another functional programmer's
Lennart says:
I've sinced changed my mind, maybe it is "a functional programmers
deathwish", but I find the case where you are explicit about what a
function depends on to be more honest and true to the FP spirit.
I've also found it practically useful since you can then change
Fergus Henderson writes:
Sigbjorn Finne, you wrote:
OK, so stdin is not a global constant anymore, but is stashed away in
TLS somewhere.
No! stdin _is_ a global constant.
What is stashed away in TLS is the binding of stdin to whichever
file it happens to be bound to. Of course if
13 matches
Mail list logo