5 ms·

I am designing a language based on OCaml/Standard ML, what are some of the problems present in these languages that can be fixed by a new design without being c

I am designing a language based on OCaml/Standard ML, what are some of the problems present in these languages that can be fixed by a new design without being constrained by a spec or backwards compatibility?

hajile 6y ago
Avoid Ocaml's syntax soup. I'd also avoid making it easy to bolt on a bunch of syntactic extensions ala camlp4 Keep your standard library standard. Module Typeclasses One, immutable string type. Make it UTF-32 by default (you can always store in a smaller format behind the scenes and extend). Make it multiline. Allow variable interpolation (typeclasses should help). SML structural typing and anonymous records are better than nominal typing. Skip on syntax bloat like named parameters. Overload your math operators instead of having special float operators like Ocaml (once again, typeclasses make this much easier). Rethink imports. F# requires you to add tons of files in the correct order to an XML. Ocaml imports all the things from the folder and blows up if you use the same module name twice. SML needs to standardize `use`. I'd recommend something like JS static import statements. If you build good documentation, good compiler errors and good tooling, more people coming to the project and help make a better compiler (a reversal of this is the big issue with SML right now in my opinion).
- maattdd 6y ago
  Anonymous record in SML is equivalent to polymorphic record in OCaml ? (basically, "structural" record)
c-cube 6y ago
Use utf8 strings, not utf32. It's the standard in most new languages for good reasons. Have a standard iterator type. Syntax wise, something closer to rust would help newcomers (see ReasonML maybe).
- red2awn 6y ago
  Do you think it make sense to include a character type that is basically a variable-size utf8 extended grapheme cluster?
toolslive 6y ago
- you want `deriving` - you might want to look at staging (MetaOCaml) - you might want to look at resource management (uniqueness typing fe) - you might want to look at paralellism and maybe you can even release it before Ocaml/multicore arrives ;)

hajile 6y ago

Avoid Ocaml's syntax soup. I'd also avoid making it easy to bolt on a bunch of syntactic extensions ala camlp4 Keep your standard library standard. Module Typeclasses One, immutable string type. Make it UTF-32 by default (you can always store in a smaller format behind the scenes and extend). Make it multiline. Allow variable interpolation (typeclasses should help). SML structural typing and anonymous records are better than nominal typing. Skip on syntax bloat like named parameters. Overload your math operators instead of having special float operators like Ocaml (once again, typeclasses make this much easier). Rethink imports. F# requires you to add tons of files in the correct order to an XML. Ocaml imports all the things from the folder and blows up if you use the same module name twice. SML needs to standardize `use`. I'd recommend something like JS static import statements. If you build good documentation, good compiler errors and good tooling, more people coming to the project and help make a better compiler (a reversal of this is the big issue with SML right now in my opinion).

maattdd 6y ago
Anonymous record in SML is equivalent to polymorphic record in OCaml ? (basically, "structural" record)

c-cube 6y ago

Use utf8 strings, not utf32. It's the standard in most new languages for good reasons. Have a standard iterator type. Syntax wise, something closer to rust would help newcomers (see ReasonML maybe).

red2awn 6y ago
Do you think it make sense to include a character type that is basically a variable-size utf8 extended grapheme cluster?

toolslive 6y ago

- you want `deriving` - you might want to look at staging (MetaOCaml) - you might want to look at resource management (uniqueness typing fe) - you might want to look at paralellism and maybe you can even release it before Ocaml/multicore arrives ;)