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
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
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
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
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
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
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
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
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
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
| -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
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..
12 matches
Mail list logo
