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

[Peter Verswyvelen]

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>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> wrote:
> >
> >
> > On Thu, Aug 20, 2009 at 2:52 AM, Jules Bean <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
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090820/eb7dc0d8/attachment-0001.html