How about integrating psuedoconstants along the lines of the existing `main'
mechanism. Each `Main' module would come with a `main' and `setup' function,
> main:: IO ()
> setup:: IO t
where `t' represents an arbitrary monotype. These definitions would
induce a binding:
> environment:: t
With
In retrospect, I think that Sigbjorn is probably right that the added
complexity of psuedoconstant and performOnceBeforeMain outweigh their
usefulness, given that only this argv debate has been demonstrated as an
instance of the problem they solve. (Unlike Fergus, I don't think that the
ability
alastair> There's a second problem with "pseudoconstant" that no-one's mentioned
alastair> yet - it breaks the Haskell type system (when used in conjunction with
alastair> mutable variables).
You tacitly imply that pseudoconstants are let-bound. The problem
disappears if you simply
Claus writes:
| Let me see if I understand the rules of this firestorm game: You have
| to repeat your ideas some times to push them through the competition?-)
Actually I think that is a poor way to proceed. That is why I have stopped
sending on this topic --- I have already said what I think
Sigbjorn Finne wrote:
[Regarding `performOnceBeforeMain' / `pseudoconstant':]
> - It's an interesting idea, but before delving into some of the
> more specific problems with it, is it really solving a general
> enough problem? [...] Are there other compelling, general uses
> of the constru
Let me see if I understand the rules of this firestorm game: You have
to repeat your ideas some times to push them through the competition?-)
Okay, here we go (simplified proposal follows at the end):
1) the functional solution to the argv-problem would use definitions
local to a local coll
> Phil writes:
> > I support those who argue AGAINST making argv a constant.
> > If it's a problem, let's find a general solution.
> >
> > One possible solution is a new declaration, of the form:
> >
> > pseudoconstant
> >
> > where has type (IO t), and is declared with type t.
> > (Pic
Phil Wadler wrote:
> If it's a problem, let's find a general solution.
>
> One possible solution is a new declaration, of the form:
>
> pseudoconstant
>
> where has type (IO t), and is declared with type t.
> (Pick a different keyword if you prefer.) The only tricky issue is
> the o
Phil writes:
> I support those who argue AGAINST making argv a constant.
> If it's a problem, let's find a general solution.
>
> One possible solution is a new declaration, of the form:
>
> pseudoconstant
>
> where has type (IO t), and is declared with type t.
> (Pick a different key
Phil writes:
>
> > I'd actually prefer if stdin&stdout were not constants, but argv was ;)
> > Having operators just like getArgs for the standard handles
> >
> > getStdin :: IO Handle
> > getStdout :: IO Handle
> > getStderr :: IO Handle
> >
> > would not prevent an implementation fro
Sigbjorn wrote:
> I'd actually prefer if stdin&stdout were not constants, but argv was ;)
> Having operators just like getArgs for the standard handles
>
> getStdin :: IO Handle
> getStdout :: IO Handle
> getStderr :: IO Handle
>
> would not prevent an implementation from providing use
I support those who argue AGAINST making argv a constant.
If it's a problem, let's find a general solution.
One possible solution is a new declaration, of the form:
pseudoconstant
where has type (IO t), and is declared with type t.
(Pick a different keyword if you prefer.) The only
Sverker Nilsson wrote:
>In Ada they have structured a similar kind of code inclusion with
>something called "subunits".
. . .
>body_stub ::=
> subprogram_specification IS SEPARATE
>|PACKAGE BODY package_simple_name IS SEPARATE;
>|TASK BODY task_simple_name IS SEPARATE;
>
>
I, Sverker Nilsson wrote:
> > I would claim it has really nothing to do with first-class modules
> > or parameterized modules. They can be simulated by ordinary Haskell
> > data types with named fields.
Lennart Augustsson wrote:
> No they can not. Haskell records do not allow local polymorphism
Holy cow! It's been a long time since I've had my mailbox packed with
letters from the Haskell list. Just when I was beginning to wonder if there
were still other people writing Haskell programs... :)
> | First, Simon, I think you're a little biased on this issue. I'm sure that
> | making ar
Indeed, what a firestorm!
> I think this is a good compromise, leave System.getArgs as it is
> and have a new extension module called SystemExt (?) that would
> contain constants for argv and the environment (and leave room for
> growth for other System overflow). If it turns out that at
> some f
> I would claim it has really nothing to do with first-class modules
> or parameterized modules. They can be simulated by ordinary Haskell
> data types with named fields.
No they can not. Haskell records do not allow local polymorphism,
so you have a significant loss of power.
-- Lennar
Claus Reinke wrote:
[Snip nice module explanation/suggestion]
> Of course, if your MyCompiler had only one entry function, a local
> definition instead of the local module would do:
>
> MyCompiler argv =
> let
> parse =
> type =
> ...
> in parse >> type >> ..
>
Sigbjorn Finne wrote:
>
> If I'm understanding Lennart and you correctly (finally, I hear you
> say!), the representation you prefer, would have an implementation
> something like the following in a multi-threaded setting:
>
> data Handle
>= Stdin
>| Stdout
>| Stderr
>| Other
Sigbjorn Finne, you wrote:
>
> ... the issue here is *not* how you configure your programs, there's more
> than one way to do that (to paraphrase the Perl slogan), but the fact that
> argv is *constant* and should be provided as such. I've yet to see a
> post contending that argv isn't.
I pointe
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 your thread implementation
doesn'
Fergus Henderson <[EMAIL PROTECTED]> writes:
>
> I pointed out that although argv is constant over any single program
> execution, it variables from execution to execution, so it's not
> really constant.
>
It is constant within the lexical scope of an executing program;
that's constant enough f
Lennart Augustsson <[EMAIL PROTECTED]> writes:
>
...
> Can't we agree on a name and make it one of the "commonly
> implemented extensions" to Haskell? That way I can still
> feel that Haskell is pure, but if you feel the urge to use
> it you can still do it. I'd actually prefer the performOnce
Sverker,
I would like to know more about your Haskell persistency library.
In this case what does the word persistency mean ?
Tim
--
--
T.R.BARBOUR Email : [EMAIL PROTECTED]
---
Simon L Peyton Jones, you wrote:
>
> 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
Simon L Peyton Jones, you wrote:
>
> Lennart, Fergus,
>
> re this stdin issue you're missing the point I was trying to make.
Yes, I am indeed missing your point.
> It really only bites badly when you have concurrency. I enclose the relevant
> message, which gives an example of the extra exp
Joe Fasel, you wrote:
>
> 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]}
> >
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, making them non-constant doesn't
give you any extra expressivene
Just some more comments from me about argv.
It's not that I hate a global argv, in fact hbc has come with a
library with a global argv since day 1 (and global program name,
environment, and file system as well. Why stop at argv?)
I use the global argv now and then, but when I do also
feel that
Koen Claessen, you wrote:
>
> Fergus Henderson <[EMAIL PROTECTED]> wrote:
>
> | Second, how do you handle syntax errors in the command line arguments?
> | What does lookupInt do if the integer overflows, or if the argument
> | is not valid syntax for an integer? Do you check for misspelt or
"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 a
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 c
> 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
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 being used appropriately. I can
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 chang
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, making them non-constant
Sverker Nilsson <[EMAIL PROTECTED]> wrote:
> So if it turns out to be possible to make the environment a constant,
> it should open up possibilities for other constants as well. I
> would rather see a general mechanism. Something like:
>
> performOnceBeforeMain:: IO a -> a
>
> timeStarted = pe
Sverker Nilsson wrote:
>
> Anyway, what it seems to me you lose by doing it the way you described
> is that you are stuck again if some day you want to set those flags
> some other way than from the environment variables. For example with
> pragmas.
Or for another example, perhaps you would like
> > 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
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
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
> > 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.
> "Simon" == Simon L Peyton Jones <[EMAIL PROTECTED]> writes:
> | Anyway, what it seems to me you lose by doing it the way you described
> | is that you are stuck again if some day you want to set those flags
> | some other way than from the environment variables. For example with
> | pragmas
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'
Claus Reinke wrote:
> `First class modules' are just that: modules that are also first
> class data objects of the programming language (e.g., records
> containing functions).
I would alter that to "(e.g., records containing functions _and
types_)", at least for statically typed pr
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 jvlA
My, what a firestorm! The Haskell mailing list springs to life.
Frank writes
| First, Simon, I think you're a little biased on this issue. I'm sure that
| making argv a global constant would be a practical benefit for programs like
| GHC.
You're probably right. I am certainly biased towar
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
>
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
Lennart, Fergus,
re this stdin issue you're missing the point I was trying to make. It
really only bites badly when you have concurrency. I enclose the relevant
message, which gives an example of the extra expressiveness non-constant
stdin etc buys you -- I don't know which bit you disagree w
Simon L Peyton Jones wrote:
>
> I agree with Sigbjorn about argv, rather strongly, though apparently nobody
> else does.
No, I agree Sigbjorn's proposal is probably a good idea, although I don't
feel strongly either way. (I was just disagreeing with the reasoning that
he used to motivate it.)
Koen Claessen <[EMAIL PROTECTED]> writes:
>
.
>
> This is also the case for making stdin a constant or not. I think stdin IS
> a constant, and should stay that way. If some bad programmer wrote a
> function that only worked on the stdin and stdout, than he limited the
> users of his/her fun
Fergus Henderson <[EMAIL PROTECTED]> wrote:
| Second, how do you handle syntax errors in the command line arguments?
| What does lookupInt do if the integer overflows, or if the argument
| is not valid syntax for an integer? Do you check for misspelt or
| invalid option names?
The point Sim
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
Simon Peyton Jones wrote:
> It was Just Too Painful to pass the flags everywhere. For example, deep in
> some dark corner of the transformation system there's a constant that
> says how big a function body can be before GHC inlines it. Threading
> the command-line arguments all the way to that s
Sigbjorn Finne, you wrote:
>
> > It certainly has its advantages, but I must say that I'm leaning
> > in the Haskell direction now. Having the arguments and the environment
> > (and why not standard input, and maybe all the files in the file system?)
> > as global constants means that your progr
>
> > What are first class modules ? Can you give a reference (preferably
> > online) ?
>
> Modules can be viewed as records. See Luca Cardelli and Peter Wegner:
> "On Understanding Types, Data Abstraction, and Polymorphism".
>
> Claus Reinke has a virtual bookshelf devoted to modules at
>
> "Stefan" == Stefan Kahrs <[EMAIL PROTECTED]> writes:
> In a certain sense you have No. 4 already: it's called newtype. Newtypes
> can be recursive. Syntactically the constructors are still there, but
> that's only to help the type inference.
As I understand it, the purpose of newtype is
Fergus Henderson writes:
>
> > module CmdLineOpts where
> >
> > argv = unsafePerformIO getArgs
> >
> > unfoldSize :: Int
> > unfoldSize = lookupInt "-funfold-size" argv
> >
> > useCleverFiniteMap :: Bool
> > useCleverFiniteMap = lookup "-fclever" argv
>
> I have a
> What are first class modules ? Can you give a reference (preferably
> online) ?
Modules can be viewed as records. See Luca Cardelli and Peter Wegner:
"On Understanding Types, Data Abstraction, and Polymorphism".
Claus Reinke has a virtual bookshelf devoted to modules at
http://www.inform
> There's a difference between the handle and its contents.
> stdin etc. really are constant, it is just their contents (the
> stuff you get if you read from that handle) that may vary.
Exactly what I was going to write.
-- Lennart
| Maybe the symbol table isn't passed around to all dark corners though.
Dead right it ain't. There are plenty of places you don't need a symbol
table.
| Anyway, what it seems to me you lose by doing it the way you described
| is that you are stuck again if some day you want to set those flags
> As for recursive "newtype": Really? That's news to me. "newtype"
> definitions only have one constructor, so any recursive definition would be an
> infinite datatype. Since a newtype constructor is unlifted, this would make
> recursive newtypes pretty useless.
How about this?
newtype L
> "Magnus" == Magnus Carlsson <[EMAIL PROTECTED]> writes:
> Speaking of the pain of plumbing, a relief could be first class modules. But
> maybe this is too far away from Haskell.
And speaking of first-class modules, are they ever going to make it into
Haskell?
My Top 5 List of Things I
Fergus Henderson <[EMAIL PROTECTED]> writes:
> >
> > But 1.3 already does this, stdin,stdout&stderr are global handle
> > constants - so why not do it for something that *really* is constant?
>
> There's a difference between the handle and its contents.
> stdin etc. really are constant, it is ju
> "Magnus" == Magnus Carlsson <[EMAIL PROTECTED]> writes:
Magnus> [...]
>> However, passing around option values to the different parts of
>> your program is a major bore, so what about instead treating
>> argv for what it really is, a constant, and make it available
>> a
Folks
I agree with Sigbjorn about argv, rather strongly, though apparently nobody
else does.
The Glasgow Haskell Compiler used to deal with command-line arguments in the
way mandated by Haskell 1.3; that is, we did a getArgs at the beginning and
then passed the arguments everywhere.
I recently
[...]
> However, passing around option values to the different parts of your
> program is a major bore, so what about instead treating argv for what
> it really is, a constant, and make it available as such
> (System.argv :: [String]), say. Having it as constant has the nice
> property that
Clifford Beshers writes:
>
> I just want to note that treating the environment as a constant is
> probably not a good idea. Because environments are passed to execve,
> inherited by sub-processes, it must be possible to change,
> or at least shadow, them.
>
> If I were re-writing emacs in Hask
Lennart Augustsson writes:
>
> > I know you could go wild with monads, c. classes etc. and try to
> > squirrel away these things, but argv is a constant (in a sane world),
> > so why not treat it as such (ditto for the environment)? Thoughts?
> Well, in 1983 Thomas Johnsson and I decided that th
> I know you could go wild with monads, c. classes etc. and try to
> squirrel away these things, but argv is a constant (in a sane world),
> so why not treat it as such (ditto for the environment)? Thoughts?
Well, in 1983 Thomas Johnsson and I decided that this was the
way to go and this is the w
Old-Received: from eli.CS.YALE.EDU by vanuata with SMTP (MMTA) with ESMTP;
Tue, 14 Jan 1997 22:51:49 +
Old-Received: from curry.cse.ogi.edu by eli.CS.YALE.EDU
(8.7.1/res.host.cf-4.0)with SMTP id RAA06555; Tue,
14
72 matches
Mail list logo
