Re: [Haskell] Re: Top Level
Am Freitag, 19. Juni 2009 21:35 schrieb Ian Lynagh: So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive? I don't know anything about the package, but if putting the modules directly under Control.Reactive wouldn't make sense then it sounds to me like the package name is poor (too generic). reactive is a specific FRP implementation by Conal Elliott. So it shouldn’t be put directly under Control.Reactive since other reasonable FRP implementations exist. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Top Level
On Thu, Jun 18, 2009 at 06:03:03PM +0200, Wolfgang Jeltsch wrote: Am Mittwoch, 17. Juni 2009 11:05 schrieb Malcolm Wallace: The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive? I don't know anything about the package, but if putting the modules directly under Control.Reactive wouldn't make sense then it sounds to me like the package name is poor (too generic). Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Top Level
Am Mittwoch, 17. Juni 2009 11:05 schrieb Malcolm Wallace: The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive? Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Top Level
Am Mittwoch, 17. Juni 2009 11:29 schrieb Anton van Straaten: Malcolm Wallace wrote: The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Besides, it hardly seems necessary to emphasize Functional and Programming in the Haskell context... When we discussed where to place modules of FRP libraries in the hierarchy, it was argued that FRP had become a “brand”. It’s not just about programming reactive systems but describes a certain basic approach to it. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Top Level
Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. I do understand that hierarchical classification is inherently problematic, and will never quite fit the ways we think of our modules. But the alternative being proposed here is neither more descriptive, nor more logical. In fact, it is an abandonment of description, in favour of arbitrary naming. A package called foo-1.0 containing a module hierarchy rooted at Foo. tells me precisely nothing about its contents. It it were rooted at Military.Secret.Foo, at least I would have some clue about what it does, even if the category is inadequate or slightly misleading in certain circumstances. You may argue that only novices are disadvantaged by arbitrary names - once you learn the referent of the name, it is no longer confusing. However, I strongly believe that even experienced users are helped by the continuous re-inforcement of visual links between name and concept. After all, if you are collaboratively building a software artifact that depends on large numbers of library packages, it may not be so easy to keep your internal dictionary of the mapping between names and functionality up-to-date, and in sync with your colleagues. Being just a little bit more explicit in the hierarchy is a one-time cost at time of writing, that reaps perceptual benefits long into the future for yourself, and those maintainers who will follow you. Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Top Level
Malcolm Wallace wrote: Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. Besides, it hardly seems necessary to emphasize Functional and Programming in the Haskell context... ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Top-level -
On Thu, Nov 25, 2004 at 10:07:20AM +0100, George Russell wrote: John Meacham wrote: Now, my mdo proposal as written would have hello outputed exactly once at module start up time no matter what, whether x is demanded or not. it is equivalant to a program transformation that collects all the top level initializers and declarations, puts them all in a mdo block and runs it with the semantics explained in the fixIO paper. (with a deterministic, but partially undefined order) What happens if you write the following? y - f x - let f = something depending on x Will it know to evaluate x before y, or is this not allowed? What about if the assignments to y and x occur in different modules? Will the RTS have to analyse the dependencies to work out which order to run the assignments in?` No. The semantics are completly and precicely defined by the fixIO paper. there is a simple desugaring to haskell which I gave in my original proposal. The basic gist is that things occur almost* identically to if everything were simply placed in a single mdo block. no dependency analysis or strange translation beyond the normal haskell desugaring mechanisms is required. recursive top level declarations are no more tricky than are normal recursive lets. Yes it is possible to write divergent statements, in the same way it is possible to say bottom = bottom you can also say bottom' - return bottom' (these are actually equivalant.) Remember, that unlike normal monadic binding, this is using recursive monadic binding, meaning the results of future computations can be used as long as they arn't strictly evaluated, in the same way you can write mutually recursive variables but if both are strict in each other they will diverge :). The fact that everyone seems to get along fine despite the ability to write divergent computations with recursive lets makes me think this won't be too much for anyone to handle. John * The differences, which I elaborated on earlier are due to a monomorphic restriction on user-written 'mdo' let-bound variables which is irrelevant to the desugaring so the translation from mdo - haskell expression is slightly different than presented in the paper. -- John Meacham - repetae.netjohn ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Top-level -
John Meacham wrote (snipped): recursive top level declarations are no more tricky than are normal recursive lets. Perhaps I am missing something, but surely one very important problem with - at top level is that calling for the value of something defined by - causes the corresponding action to be performed? Unless the actions available are very tightly restricted, this means that for example the meaning of a program depends on what order arguments to a pure functions are evaluated, for example. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Top Level TWI's again was Re: Re: Parameterized Show
On 2004-11-22, Benjamin Franksen [EMAIL PROTECTED] wrote: On Monday 22 November 2004 09:38, Adrian Hey wrote: You have yet to explain how you propose to deal with stdout etc.. I see absolutely no reason why stdxxx must or should be top-level mutable objects. They can and should be treated in the same way as environment and command line arguments, i.e. getArgs :: IO [String] getEnv :: String - IO String getStdin, getStdout, getStderr :: IO Handle Note that (just like environment and command line arguments) these handles may refer to completely different things on different program runs. Er, no. The handles can be considered as the same but _pointing_ to different things on different runs. Keeping them outside the IO monad, and only accessing them inside -- i.e. the current situation -- would be fine. They're not mutable in any sense. -- Aaron Denney -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Top Level TWI's again was Re: Re: Parameterized Show
On Tuesday 23 November 2004 00:10, Aaron Denney wrote: On 2004-11-22, Benjamin Franksen [EMAIL PROTECTED] wrote: On Monday 22 November 2004 09:38, Adrian Hey wrote: You have yet to explain how you propose to deal with stdout etc.. I see absolutely no reason why stdxxx must or should be top-level mutable objects. They can and should be treated in the same way as environment and command line arguments, i.e. getArgs :: IO [String] getEnv :: String - IO String getStdin, getStdout, getStderr :: IO Handle Note that (just like environment and command line arguments) these handles may refer to completely different things on different program runs. Er, no. The handles can be considered as the same but _pointing_ to different things on different runs. I wrote may refer to, not are, so yes. Keeping them outside the IO monad, and only accessing them inside -- i.e. the current situation -- would be fine. I beg to differ. Note, I do not claim they are unsafe. They're not mutable in any sense. Well, a variable in C is not mutable in exactly the same sense: It always refers (=points) to the same piece of memory, whatever value was written to it. Where does that lead us? Ben -- Top level things with identity are evil.-- Lennart Augustsson ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Re: Top Level TWI's again was Re: Re: Parameterized Show
Can I suggest that this thread, interesting as it is, might usefully migrate to haskell-café. (Apart from anything else, there's another similar thread running there, and it makes sense to keep together.) Posting a summary back to the Haskell list, in due course, would be great. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin | Franksen | Sent: 23 November 2004 13:21 | To: [EMAIL PROTECTED] | Subject: Re: [Haskell] Re: Top Level TWI's again was Re: Re: Parameterized Show | | On Tuesday 23 November 2004 00:10, Aaron Denney wrote: | On 2004-11-22, Benjamin Franksen [EMAIL PROTECTED] wrote: | On Monday 22 November 2004 09:38, Adrian Hey wrote: | You have yet to | explain how you propose to deal with stdout etc.. | | I see absolutely no reason why stdxxx must or should be top-level mutable | objects. They can and should be treated in the same way as environment | and command line arguments, i.e. | | getArgs :: IO [String] | getEnv :: String - IO String | getStdin, getStdout, getStderr :: IO Handle | | Note that (just like environment and command line arguments) these | handles may refer to completely different things on different program | runs. | | Er, no. The handles can be considered as the same but _pointing_ to | different things on different runs. | | I wrote may refer to, not are, so yes. | | Keeping them outside the IO monad, | and only accessing them inside -- i.e. the current situation -- would be | fine. | | I beg to differ. Note, I do not claim they are unsafe. | | They're not mutable in any sense. | | Well, a variable in C is not mutable in exactly the same sense: It always | refers (=points) to the same piece of memory, whatever value was written to | it. Where does that lead us? | | Ben | -- | Top level things with identity are evil. -- Lennart Augustsson | ___ | Haskell mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Top Level TWI's again was Re: Re: Parameterized Show
On 2004-11-23, Benjamin Franksen [EMAIL PROTECTED] wrote: On Tuesday 23 November 2004 00:10, Aaron Denney wrote: On 2004-11-22, Benjamin Franksen [EMAIL PROTECTED] wrote: On Monday 22 November 2004 09:38, Adrian Hey wrote: You have yet to explain how you propose to deal with stdout etc.. I see absolutely no reason why stdxxx must or should be top-level mutable objects. They can and should be treated in the same way as environment and command line arguments, i.e. getArgs :: IO [String] getEnv :: String - IO String getStdin, getStdout, getStderr :: IO Handle Note that (just like environment and command line arguments) these handles may refer to completely different things on different program runs. Er, no. The handles can be considered as the same but _pointing_ to different things on different runs. I wrote may refer to, not are, so yes. They're wrappers around the integers 0, 1, and 2. The handles could have been implemented to be the same, at each invocation. (I expect they are in most implementations). If we had to make them ourselves, they could be done as: stdin = makeHandle 0 stdout = makeHandle 1 stderr = makeHandle 2 in absolutely pure Haskell, only the things that manipulate them need be in the IO monad. They're not the external state in the world to which they point -- just ways of instructing the OS. I don't see how sprinkling stdin - getStdin in every IO routine helps at all. The means of instructing the OS is a constant. Unlike the case with IORefs, we have an extra argument that keeps the compiler from aliasing these together. The arguments and environment really are different at each invocation, not merely referring to different things. If you add a redirection, the argument space and environment space at invocation (barring relocation) would be the same. But since there's only one, it's easier to provide access functions with the argument of where to look already applied. Keeping them outside the IO monad, and only accessing them inside -- i.e. the current situation -- would be fine. I beg to differ. Note, I do not claim they are unsafe. If it's not unsafe, and it makes for simpler (hence easier to understand, create, debug, and modify) in what sense is it not fine? They're not mutable in any sense. Well, a variable in C is not mutable in exactly the same sense: It always refers (=points) to the same piece of memory, whatever value was written to it. Where does that lead us? A slightly different sense, but I won't quibble much. It would lead us to being able to have TWIs, only readable or writeable in the IO Monad. Many people don't think that would be such a bad thing. But because of the semantics we expect from IORefs, we can't get them without destroying other properties we want. a = unsafePerformIO $ newIORef Nothing Respecting referential integrity would give us the wrong semantics. Adding labels would force the compiler to keep two differently labeled things seperate, but it would fall down for things having the same label. a = unsafePerformIO $ newLabeledIORef a Nothing b = unsafePerformIO $ newLabeledIORef a Nothing If we look at this, we could legitimately expect them to either be unified, or not be unified, but we would want consistency. Doing this uniformly seems a tough burden on compiler writers. In contrast with IO Handles, there the OS does all the work. If makeHandle were exposed to us, It really wouldn't matter whether handle1 and stdout handle1 = makeHandle 1 stdout = makeHandle 1 were beta-reduced or not. Either way, the OS naturally handles how we refer to stdout. (One caveat here -- buffering implemented by the compiler runtime would make a difference.) -- Aaron Denney -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
