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
<lenn...@augustsson.net <mailto:lenn...@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<leim...@gmail.com
<mailto:leim...@gmail.com>> wrote:
>
>
> On Thu, Aug 20, 2009 at 2:52 AM, Jules Bean
<ju...@jellybean.co.uk <mailto:ju...@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@haskell.org <mailto:Haskell-Cafe@haskell.org>
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org <mailto:Haskell-Cafe@haskell.org>
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
