Hacker News Reader

Comment by dharmatech | Hacker News Reader

This is cool! Thank you! I'm a fan of C# and dotnet. Nice that you used F#!

Thank you. The only thing I really miss in c#/dotnet are delimited continuations. That would have made it possible to have proper effect handlers (now they are only tail resumptive, meaning it can only mock things like file system access and so on) and remove colour from the language entirely.

The colour situation is ok, but us still a bit rough wrt higher order functions.

If I remember correctly MSIL has the necessary support.

https://news.microsoft.com/source/2001/10/22/massive-industr...

I am not around the MSFT Partner CDs with the .NET Framework 1.0 release, however I remember there was a Scheme compiler as part of the original samples.

So maybe target MSIL directly.

I am pretty sure dotnet doesn't allow any kind of fun (or "tampering" as they call it) with the stack, as a security precaution.

Depends how the MSIL bytecodes are used, and as long as it is done in a way that the verifier is happy, it goes.

I am curious how. I thought quite a lot about targeting MSIL, but i found no way of copying, capturing or slicing the call stack. Nor is it possible to reify even the whole stack as a first class object.

For delimited continuations I only managed to find mostly extremely inefficient ways of doing it. CPS transformations on dotnet are, at least if kept to be useful as delcc, slow as molasses.

Which is ultimately why I chose to compile to c# to use asyncmethodbuilder do do the state machine translation for me.

After some research I stand corrected, apparently only partial support is possible.

https://www.jot.fm/issues/issue_2004_10/article4

I thought otherwise given my recollection of the samples, and that the platform supports C++, thus quite flexible on the opcodes.

In many ways I feel I should have targetted OCaml instead, since I would have gotten a full effect handler system and delimited continuations for free.

Now I am generating two bodies for every defun that touches any suspending function, using asyncmethodbuilder, meaning I don't get any of the runtimeasync benefits coming in dotnet11.

Hopefully they'll give us a new asyncmethodbuilder that is somewhat more constrained but guarantees runtime async.

Reply on news.ycombinator.com