3 ms·

I can attest to this. I've just done a project in F# -- my first experience using a statically typed functional language beyond messing around in a REPL -- and

I can attest to this. I've just done a project in F# -- my first experience using a statically typed functional language beyond messing around in a REPL -- and the expressive power of this combination is intoxicating. I may have gone overboard; I found it hard to write procedural code in F#, so I split up my procedures into steps, with a type to model each step and a sum type to model the whole procedure. Coming from C / Python, where I was used to procedural code mostly working most of the time and then failing in hilarious ways, this was a revelation. A language where I can make the compiler check my procedural logic for me! Liberating!

yetanotheruser 9y ago
Does f# have a good repl? What ml style language has the closest thing approaching a lisp style repl?
- tom_mellior 9y ago
  Not saying it's the closest to what you have in mind, but you could look at the Emacs Tuareg mode for OCaml. Here is a reference card: http://www.ocamlpro.com/files/tuareg-mode.pdf http://www.ocamlpro.com/files/tuareg-mode.pdf If you are a SLIME fan, you might notice that some of the key bindings to interact with the toplevel (the OCaml word for "REPL") are identical in Tuareg. That said, although this will sound tongue-in-cheek: Having used Isabelle and Coq with their interactive editors, I find their approach better than a REPL. In these systems, you execute code directly from your source file, as opposed to (conceptually) sending snippets of code to a REPL. There is no concept of code you have written in the source (or the REPL) which is not synced up with the state of the REPL (or the source code, respectively). I wish other languages had modes like this. There seems to be one for Prolog, but I've never used it and don't know how well it works in practice: https://www.metalevel.at/ediprolog/ https://www.metalevel.at/ediprolog/
- sevensor 9y ago
  I've been happy with it. It's a good place to isolate your type issues and figure out how to plug things together. It helped me learn a lot about how F# does its type inference.
masklinn 9y ago
> I may have gone overboard; I found it hard to write procedural code in F#, so I split up my procedures into steps, with a type to model each step and a sum type to model the whole procedure. State machines are a great thing, and modelling a state machine as a sum type is reasonably common (it's not the best modelling for all state machines, but it's very good for many).
- sevensor 9y ago
  I'm glad to see I'm not totally crazy for adopting that pattern! As I'm new to the language, I'm not sure whether I'm holding it right.

yetanotheruser 9y ago

Does f# have a good repl? What ml style language has the closest thing approaching a lisp style repl?

tom_mellior 9y ago
Not saying it's the closest to what you have in mind, but you could look at the Emacs Tuareg mode for OCaml. Here is a reference card: http://www.ocamlpro.com/files/tuareg-mode.pdf http://www.ocamlpro.com/files/tuareg-mode.pdf If you are a SLIME fan, you might notice that some of the key bindings to interact with the toplevel (the OCaml word for "REPL") are identical in Tuareg. That said, although this will sound tongue-in-cheek: Having used Isabelle and Coq with their interactive editors, I find their approach better than a REPL. In these systems, you execute code directly from your source file, as opposed to (conceptually) sending snippets of code to a REPL. There is no concept of code you have written in the source (or the REPL) which is not synced up with the state of the REPL (or the source code, respectively). I wish other languages had modes like this. There seems to be one for Prolog, but I've never used it and don't know how well it works in practice: https://www.metalevel.at/ediprolog/ https://www.metalevel.at/ediprolog/
sevensor 9y ago
I've been happy with it. It's a good place to isolate your type issues and figure out how to plug things together. It helped me learn a lot about how F# does its type inference.

masklinn 9y ago

> I may have gone overboard; I found it hard to write procedural code in F#, so I split up my procedures into steps, with a type to model each step and a sum type to model the whole procedure. State machines are a great thing, and modelling a state machine as a sum type is reasonably common (it's not the best modelling for all state machines, but it's very good for many).

sevensor 9y ago
I'm glad to see I'm not totally crazy for adopting that pattern! As I'm new to the language, I'm not sure whether I'm holding it right.