[plt-scheme] Re: computational expressions

Looking here:
http://blogs.msdn.com/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspx

<http://blogs.msdn.com/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspx>It
appears at a quick glance that you can define return as a member of the
builder object, and then use that builder to reuse your special return
function.

I guess that means it takes more boilerplate to mix and match custom
computational expressions, but maybe that's a good thing.

Jeremy


On Tue, Mar 16, 2010 at 4:03 PM, John Clements <clements at brinckerhoff.org>wrote:

> Which is better? Haskell or F#?
>
> Wait, wait, no, that's not what I meant at all.
>
> I was reading up on F#'s computational expressions last night, and I'm
> impressed by their flexibility.  I do see one teeny tiny thing that's
> missing, though.
>
> In particular, it looks like computation expressions (e.g.
>
> parse { let! e = token
>       return e}
>
> Are a lot like Haskell's monads. In fact, in one way they're nicer; rather
> than just bind and return, you get a whole bunch of syntactic forms that you
> can redefine.
>
> But! If I understand correctly, these overridings happen only within the
> syntactic boundaries of the curly braces, right?  So you couldn't abstract
> over those pieces in quite the same way.
>
> E.G:
>
> let myReturn x = return x;;
>
> parse { let! t = token
>        myReturn t}
>
> ... wouldn't work, right?
>
> Whereas Haskell gets it right:
>
> myReturn = return
>
> p = do t <- token
>       myReturn t
>
>
>
> I haven't tried actually running any of this, mind you. Of course, Scheme
> can't do this, either; it's a consequence of Haskell's truly insane type
> system.
>
>
> John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100316/2e14abf3/attachment.html>