[Haskell-cafe] Re: Where do I put the seq?

[Dan Weston]

Peter,

I think you are right that there is no way in general to prevent a valid 
graph rewrite to remove a vacuous dependency. That is why seq is there.

The funny business is visible right in the type signature of seq:

seq :: forall a t. a -> t -> t

If seq had nonstrict semantics, this would be isomorphic to t -> t, 
which is inhabited only by id. So, if seq is going to have any useful 
effect, it must be strict. Since Haskell is nonstrict by default (absent 
some deconstruction, which requires knowledge of the value 
constructors), you need an extra-language primitive to do this. Don't 
look to "case" to do this.

And other strictifying syntax constructs like ! are just syntactic 
sugar, so they don't count.

Dan

Peter Verswyvelen wrote:
> I totally agree that data dependencies are the best way to do that. And 
> I'm beginning to see why interact might not be suitable for 
> demonstrating FRP. 
> 
> On the other hand, when you say data dependencies, you mean that the 
> value of expression A depends on the value of expression B, but what if 
> that value is not really needed? 
> 
> For example, suppose you want a program that asks the name of the user 
> and then outputs "What a nice name" or "What a weird name" depending on 
> some random value. Even though the input value from the user is not 
> used, we still can't output the text before the input is entered. Again 
> the hidden dependency is time itself I guess, so we should do it the 
> real FRP way, even with dumb console text IO.
> 
> Also doesn't Haskell's IO system uses a hidden RealWorld type that has 
> no value but which is passed from between monadics binds in a strict way 
> to make the ordering work? So IO in Haskell is a horrible hack then? :-) 
> If it would be done nicely, in the FRP way, then RealWorld IO would need 
> time stamps to get rid of the hack?
>   
> So to do console IO the FRP way (say like in Reactive), the input lines 
>  from the user would be Event String, and the output also Event String. 
> Each event occurrence has a time stamp, and when merged, they would be 
> ordered. It would be nice to show this example in Reactive. Too bad 
> Reactive doesn't work (and it's not sure it ever will according to the 
> comment of some users), but for a simple example like this, I'm sure it 
> works. In Yampa, I'm not sure how console based IO would work, I guess 
> it would need to generate event non-occurrences (Nothing) when the user 
> did not type anything, and we would need non-blocking IO, so 100% CPU 
> load, since it's pull based, not sure, to be investigated. I haven't 
> worked with Elerea nor Grapefruit yet, but I'm not sure if I should 
> treat the former as a real FRP system since it is not referentially 
> transparent (it would be nice to know which combinators break it).
>  
> On the other hand, in this simple example, I could use a strict field in 
> an ADT to enforce the input-output dependency, but I guess this is just 
> the same big hack? 
> (see http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8316#a8367)
> 
> This silly example is causing lots of feedback, cool :-)
> 
> On Thu, Aug 20, 2009 at 7:12 PM, Lennart Augustsson 
> <lennart at augustsson.net <mailto:lennart at augustsson.net>> wrote:
> 
>     Using seq to control a program's semantics (as in, input-output
>     behaviour) is a horrible hack.
>     The seq operation there to control space and time aspects of your
>     program.
>     (The specification of seq doesn't even say that the first argument is
>     evaluated before the second one.)
>     You should use data dependencies to control your program's semantics.
> 
>     On Thu, Aug 20, 2009 at 4:34 PM, David Leimbach<leimy2k at gmail.com
>     <mailto:leimy2k at gmail.com>> wrote:
>      >
>      >
>      > On Thu, Aug 20, 2009 at 2:52 AM, Jules Bean
>     <jules at jellybean.co.uk <mailto:jules at jellybean.co.uk>> wrote:
>      >>
>      >> Peter Verswyvelen wrote:
>      >>>
>      >>> Not at all, use it for whatever you want to :-)
>      >>>
>      >>> I'm writing this code because I'm preparing to write a bunch of
>     tutorials
>      >>> on FRP, and I first wanted to start with simple console based
>     FRP, e.g.
>      >>> making a little text adventure game, where the input/choices of
>     the user
>      >>> might be parsed ala parsec, using monadic style, applicative
>     style, and
>      >>> arrows, and then doing the same with FRP frameworks like
>      >>
>      >>
>      >> This is a really bad place to start a FRP tutorial IMO.
>      >>
>      >> The interface for 'interact' does not make any promises about
>     the relative
>      >> evaluation order of the input list / production order of the
>     output list.
>      >>
>      >> That's why you are having to play horrible tricks with seq to
>     try to force
>      >> the order to be what you want.
>      >>
>      >> I don't think this is the basis of a robust system or a sensible
>     tutorial.
>      >>
>      >> Just my 2c.
>      >
>      > Interesting feedback, but I don't get the reason really.  How is
>     using seq a
>      > "horrible trick"?  It's there for strict evaluation when you need
>     it, and in
>      > this case it was warranted.
>      > And as far as saying it's not a good basis for a robust system,
>     I'm also not
>      > sure I agree, but a "sensible tutorial", that I could believe as
>     I think
>      > it's actually quite difficult to explain these topics to people
>     in a way
>      > they're going to understand right away.
>      > Could we perhaps bother you to suggest an alternative along with your
>      > criticism?  It would feel a little more constructive at least
>     (not that I
>      > think you were being terribly harsh)
>      > Dave
>      > _______________________________________________
>      > Haskell-Cafe mailing list
>      > Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>      > http://www.haskell.org/mailman/listinfo/haskell-cafe
>      >
>      >
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
>