Send Beginners mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1. Re:  FRP (Kim-Ee Yeoh)
   2. Re:  an observation about Haskell vs. Python (Kim-Ee Yeoh)
   3. Re:  an observation about Haskell vs. Python (Kim-Ee Yeoh)


----------------------------------------------------------------------

Message: 1
Date: Fri, 21 Sep 2012 12:06:44 +0700
From: Kim-Ee Yeoh <[email protected]>
Subject: Re: [Haskell-beginners] FRP
To: Ertugrul S?ylemez <[email protected]>,  Heinrich Apfelmus
        <[email protected]>
Cc: [email protected]
Message-ID:
        <CAPY+ZdR9voiudcZ_LjMm+6n0MM=gqa9ov2dkcsgciykj-af...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Move to haskell-cafe you two.

(j/k -- I think the discussion is great here. If you also cc'ed -cafe, your
points would get higher visibility.)


-- Kim-Ee


On Fri, Sep 21, 2012 at 8:53 AM, Ertugrul S?ylemez <[email protected]> wrote:

> Heinrich Apfelmus <[email protected]> wrote:
>
> > > Wire is also an Alternative, which allows concise and efficient
> > > switching with very little cruft.  The following wire renders "yes"
> > > when the "keyDown Space" event happens and "no" otherwise:
> > >
> > >     pure "yes" . keyDown Space <|> pure "no"
> > >
> > > Or with the OverloadedStrings extension:
> > >
> > >     "yes" . keyDown Space <|> "no"
> > >
> > > All classic (non-wire) FRP implementations need switching or another
> > > ad-hoc combinator for this.  If you happen to need switching it's
> > > also a lot simpler using wires:
> > >
> > >     "please press space" . notE (keyDown Space) --> "thanks"
> > >
> > > This one waits for the Space key and then outputs "thanks" forever.
> > > So far Netwire has the fastest and most elegant way of dealing with
> > > events compared to all other libraries I have tried.
> >
> > These examples look neat!
> >
> > I'm a bit confused about the model you are using, though. If I
> > understand that correctly, you don't distinguish between events and
> > behaviors; rather, you are working with data streams in discrete time
> > steps. Still, I don't quite understand.
>
> First let me try to put reactive-banana's model into a data type of my
> own, which you might call TimedZipStream.  The name Behavior is easier,
> so let me pick that one instead (Time is the type for time deltas):
>
>     newtype Behavior a =
>         Behavior {
>           stepBehavior :: Time -> Network (a, Behavior a)
>         }
>
> This is not anywhere near how reactive-banana represents its behaviors,
> but just a simplified and less powerful model.  The argument is the time
> delta to the last instant.  Communication happens through the Network
> monad and is opaque to the user.  The type is an applicative functor
> that represents values that can behave differently at each instant.
>
> My model is similar to Yampas model, where instead of time-varying
> values you have time-varying functions, so-called signal functions:
>
>     newtype SF a b =
>         SF {
>           stepSF :: Time -> a -> (b, SF a b)
>         }
>
> This is a function from an 'a' to a 'b' that mutates over time.  There
> is a counterpart for classic behaviors, which is when the input type is
> fully polymorphic:
>
>     time :: SF a Time
>
> SF forms a family of applicative functors, but now there is a direct
> path from one signal function to the next, because SF is itself a
> category.  No graph, no monad, just plain categorical composition.
> Unfortunately to this day Yampa does not provide an Applicative
> instance, so you have to use the Arrow interface, which is usually very
> ugly.
>
> The weak spot of both models is events.  They need to be handled using
> switchers and other combinators.  Causality, simultaneity and choice all
> need to be encoded explicitly.  Event modifiers work outside of the
> behavior level.
>
> What makes Netwire different?  Wire categories are encoded by the
> following (simplified) type:
>
>     newtype Wire e a b =
>         Wire {
>           stepWire :: Time -> a -> (Either e b, Wire e a b)
>         }
>
> Wires can choose not to output anything, but instead inhibit with a
> value of type 'e'.  Where i is an inhibiting wire the following
> identities hold:
>
>     x . i = i
>     i . x = i
>
> Furthermore now when 'e' is a Monoid Wire is a family of Alternative
> functors with the following identities, where x and y produce and i, j
> and ij' and inhibit:
>
>     x <|> y = x
>     i <|> y = y
>
>     i <|> j = ij'
>
> The ij' wire also inhibits, but mappend-combines the inhibition values.
> The empty wire always inhibits with mempty.  The monoid is necessary for
> the Category, Applicative and Alternative laws to hold.
>
>
> > What is
> >
> >      pure "yes" . keyDown Space <|> pure "no"
> >
> > supposed to mean? If it's a function Time -> String , how long does it
> > have the "yes" value? 439.7 milliseconds? If it's an event, how often
> > does the "no" event fire?
>
> An event wire is a wire that acts like the identity wire when it
> produces, but may choose to inhibit instead:
>
>     pure "yes" . keyDown Space
>
> The 'keyDown Space' wire acts like the identity wire when the space key
> is pressed, otherwise it inhibits.  As a consequence of the above laws
> the composition also inhibits.  This is where (<|>) comes in:
>
>     pure "yes" . keyDown Space <|> pure "no"
>
> When the left wire inhibits, the right wire takes over.  By definition a
> 'pure' wire never inhibits.  Notice that in this example I'm assuming
> that 'keyDown' is a 'continuous event'.  That's where behaviors are
> mixed with events.  An event can actually have a duration.
>
> If 'keyDown' would be instantaneous without a duration you could use the
> 'holdFor' combinator:
>
>     pure "yes" . holdFor 1 (keyDown Space) <|> pure "no"
>
> This would also work for a continuous 'keyDown' event wire.  Then if you
> press the space key for one second, "yes" is displayed for two seconds.
>
>
> > Concerning the other example, I don't understand what the expression
> >
> >     "please press space" . notE (keyDown Space)
> >
> > means. If it's a function, what value does it have when the key was
> > pressed? If it's an event, how often does it "fire" the string value?
>
> In this case it doesn't really matter if 'keyDown Space' has a duration
> or not.  As soon as it produces once, the switch happens and the next
> wire takes over.  There is another name for the (-->) combinator called
> 'andThen'.
>
>     x --> y
>
> As soon as x inhibits, this combination switches to y.
>
> Side note:  Unlike classic FRP a wire category is not time-bound.  In
> fact in the current official release of Netwire (3.1.0) time is actually
> an extension.  In Netwire time is back as a primitive, because it makes
> time-related wires (the analog to behaviors) much easier to write.  I
> have retained the flexibility that your wire can have a time frame
> different from real time, though.
>
>
> Greets,
> Ertugrul
>
> --
> Not to be or to be and (not to be or to be and (not to be or to be and
> (not to be or to be and ... that is the list monad.
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20120921/219ed670/attachment-0001.htm>

------------------------------

Message: 2
Date: Fri, 21 Sep 2012 12:30:12 +0700
From: Kim-Ee Yeoh <[email protected]>
Subject: Re: [Haskell-beginners] an observation about Haskell vs.
        Python
To: Dennis Raddle <[email protected]>
Cc: Haskell Beginners <[email protected]>
Message-ID:
        <capy+zdrwkwidfatpwxg5nctun2zar-zsaouhtrrtf84pi89...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Sep 20, 2012 at 10:33 AM, Dennis Raddle <[email protected]>
 wrote:

> In Haskell you give up easy-to-comprehend error messages and mutable data,
> and get back in reward a lot of reassurance that your program does what you
> meant and expressivity.
>

It's an interesting observation you made earlier, thanks!

I'd also add that the gnarlier errors are because of code maxing out the
newer innovations of the type system. Haskell98, comparatively, isn't half
as terrifying.

But type safety is a drug. You never get enough of it.

One way to contain the complexity is to note what packages viralize their
pragmas, i.e. require client code to turn on the same pragmas that they do.



-- Kim-Ee


On Thu, Sep 20, 2012 at 10:33 AM, Dennis Raddle <[email protected]>wrote:

>
>
> Thanks. I'm okay with the status quo.. I just see it as a tradeoff. You
> are giving up something to get something. In Python you give up any kind of
> compile-time type checking, you give up the safety of immutable data, and
> you get a whole lot of automatic type conversions and brief ways to express
> certain algorithms. In Haskell you give up easy-to-comprehend error
> messages and mutable data, and get back in reward a lot of reassurance that
> your program does what you meant and expressivity. (I realize Haskell has
> mutable data but it's not like Python's)
>
> On Wed, Sep 19, 2012 at 7:43 PM, Ertugrul S?ylemez <[email protected]> wrote:
>
>>
>>     Notice:  You probably forgot to apply `sin' to an argument.
>>
>> However, I think that no work is done on that, and there is another
>> possible path:  An average Haskell tutorial should always include a
>> section on understanding error messages.  In fact the latest issue of
>> The Monad Reader [1] has an article on that by Jan Stolarek.
>>
>> [1]: http://themonadreader.files.wordpress.com/2012/08/issue20.pdf
>>
>>
>> Greets,
>> Ertugrul
>>
>> --
>> Not to be or to be and (not to be or to be and (not to be or to be and
>> (not to be or to be and ... that is the list monad.
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20120921/b781e799/attachment-0001.htm>

------------------------------

Message: 3
Date: Fri, 21 Sep 2012 12:36:01 +0700
From: Kim-Ee Yeoh <[email protected]>
Subject: Re: [Haskell-beginners] an observation about Haskell vs.
        Python
To: David Hinkes <[email protected]>
Cc: Haskell Beginners <[email protected]>
Message-ID:
        <CAPY+ZdQ+bG7Xinyr9kAuJmW=t-mgc_s_dcjtkoupmqkqaiq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Sep 20, 2012 at 8:24 AM, David Hinkes <[email protected]>
 wrote:

> I almost think of the unit tests as the compiler (does that make sense to
> anyone but me?).
>

Absolutely! There's also quickcheck, which is semi-automated fuzz testing.
All this contributes to greater awesomeness in every line of code.


-- Kim-Ee


On Thu, Sep 20, 2012 at 8:24 AM, David Hinkes <[email protected]>wrote:

> With python (and any other non-compiled language for that matter) the unit
> testing is very important.  I almost think of the unit tests as the
> compiler (does that make sense to anyone but me?).
>
>  On Wed, Sep 19, 2012 at 3:15 PM, Dennis Raddle 
> <[email protected]>wrote:
>
>>  As a somewhat-newbie haskell user and longtime Python user, what I have
>> observed is this.
>>
>> Haskell creates compile-time error messages that are somewhat hard to
>> understand for beginners.
>>
>> Python (or any scripting language) creates run-time bugs that are hard to
>> understand.
>>
>> One reason for the weird (to a beginner) compile errors in Haskell is its
>> expressivity -- almost any sequence of identifiers could potentially mean
>> something, and if you make a mistake, the compiler is sure to find some
>> "weird" way to interpret it.
>>
>> But Python suffers from a similar problem -- it's not as expressive a
>> language, but it is very permissive, not insisting on type correctness,
>> order of arguments, or any of a number of things so that the programmer can
>> write a program that compiles with no errors -- but has strange run-time
>> bugs.
>>
>> I'll take Haskell. I'm a bit OCD about getting the bugs out of my
>> programs, and Python just opens up too many holes for me to relax with it.
>>
>> Dennis
>>
>>
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>>
>
>
> --
> David Hinkes
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20120921/dc05c3d8/attachment.htm>

------------------------------

_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 51, Issue 34
*****************************************

Reply via email to