15 comments

[ 3.0 ms ] story [ 37.2 ms ] thread
The biggest problem for me is that I can't find a simple way to get started with Coalton.

I'm not a common lisp user, but I want to be. I want to learn common lisp, and I have a fair understanding of types. I think types can benefit the user in understanding more, as well as the inbuilt "intelligence" - (aka: How am I meant to know ahead of time that I can't add these two objects together? Having the editor tell me as I'm writing is a great step)

I have "mine" their text editor, now I just need some tutorials and sample projects to go with it.

Ask an llm how to setup.

This is one area where they excel at with no caveats.

Now that the native ocaml repl has landed, can't we just slap a s-expression syntax on top of ocaml and call it a day? We would have homoiconicity and the macros that go with it, and still could call "(compile `some-code)". Isn't that enough?
Nothing will ever be enough, for all interpretations of the statement, reveling in all the irony, pathos, and prideful triumph that could possibly be extracted from such interpretations from here to eternity

Humans will keep inventing and remixing

We have a deep capacity for remixing.
I'd love that. The janky OCaml syntax is my least favorite part of the language.
Aside from the fact that slapping an s-expression syntax on top of a language typically leaves you with a fairly crappy Lisp, that would also lack the excellent Common Lisp interop that Coalton has.
OCaml is a better candidate than most. It already has a macro system (PPX), and the core language has a lot in common with Scheme.
> native ocaml repl has landed

What does this refer to? Most people use the OCaml `utop` REPL which isn't okay for some printf debugging but nowhere near what a Lisp could do.

The words "Statically Typed" and "Haskell" made me click on something lisp related for once.
So is there something like IO-Monad in Coalton?

I think that's the greatest feature of Haskell. Divide every program into two parts, one that can have side-effects and one that can not.

So, Greenspun's Tenth Rule seems to have come full circle: now, "Any sufficiently complicated Coalton program contains an ad hoc, slow implementation of half of OCaml." ;)

I've left out "informally specified, bug-ridden" because I guess that's not the case for Coalton, but kept "slow" for when Coalton is used on a slower CL implementation.