879
views3
comments

Can this be done in a better way in F#?

Well, yes, you could use seq{...}, but you said

is there a better way to accomplish the same w/o resorting to the built in c# yield return state machines?

and the F# seq{...} is like the C# yield return state machine.

I guess I don't understand what you're asking or why you're asking it.

By brianmcn on 4/22/2010 9:50 AM (permalink)

The reason is pretty much that I want some basic enumerator with "movenext" support in my toy language "Plastic"

I'm writing it in F#

I do have standard enumerator support using closures right now, so I can foreach and break such loops.

But to support the movenext scenario I need to keep enumerator state alive.

C# resorts to code transformation to build statemachines.

JRuby cheats and uses threads to keep the callstack of the enumerator alive.

Plain Ruby uses fibers to do the same (i think)

I want to simulate that effect.

Thats why.

So I thought it might be possible to do some nifty async F# tricks to do the same.

By Roger_Alsing on 4/22/2010 11:22 AM (permalink)

Why can't you keep the seq alive? If it's referenced, it should be alive and maintain state, no? - regardless of implementation details.

By anotheraccount on 4/27/2010 11:46 AM (permalink)

Topic tags

Built with WebSharper