Comments for Ramon Snir on F#

Comment on Being responsible when using tail recursion and exceptions by Johann Deneux

Johann Deneux — Mon, 19 Dec 2011 09:17:00 +0000

IMHO, using attributes to document functions isn’t optimal, comments are a better fit for that. I think attributes should be used only in cases where you expect tools to process them automatically.

You indirectly highlighted an interesting side-effect of type inference: “with stack overflow“ doesn’t have int64 as return type. It has helped me detect bugs and infinite recursions in my code before executing it in a couple occasions.

Comment on The Lazync Computation Expressions by Ramon Snir

Ramon Snir — Sun, 11 Dec 2011 20:04:57 +0000

Gustavo: you’re welcome to add it!

Comment on The Lazync Computation Expressions by Gustavo Guerra

Gustavo Guerra — Sun, 11 Dec 2011 20:01:26 +0000

This is really cool. You should add this monad to the fsharpx library

Comment on The Lazync Computation Expressions by Jason

Jason — Tue, 16 Aug 2011 04:20:45 +0000

Useful, thanks

Comment on Taking Computation Expressions one step further by Ramon Snir

Ramon Snir — Sun, 03 Apr 2011 14:19:37 +0000

@MBR: I am a big fan of DSLs, so I felt it is really missing from F#. If you want to keep inside the functional paradigm, you should also be careful with regular computation expressions (e.g. Tomas Petricek’s imperative monad).

I think that the e-monads are a good place to start when designing a DSL – you got a good basis, but you are still limited to F# logic.

Comment on Taking Computation Expressions one step further by MBR

MBR — Sun, 03 Apr 2011 00:45:58 +0000

Arg – that was only half my response…
Anyway, good work getting in there and extending the compiler…

Comment on Taking Computation Expressions one step further by MBR

MBR — Sat, 02 Apr 2011 16:31:27 +0000

I think this sort of capibility is needed in F# – the ability to express DSL’s in the language.
But when you go this far past computation you’re no longer using a functional paradigm, but just emulating a macro system, with the restriction that you must over-load existing keywords – this seems like the worst of both worlds. We should just have a user-definable sub-grammar inside of {}’s, and real macros that when run take the expression tree as input, and output another one which is compiled. (Template-matching using the user-defined grammar would also be a plus.)