Custom syntax sets

Hi there :slight_smile:

I am new to both, this community and programming. I read a lot about theoretical aspects in the past weeks and like OCaml for its distraction free code, it looks really easy to understand.

Reason seems to solve a couple of issues, like with pattern matching and tuples, while a lot of the other stuff confuse the language, just in order to make all more Javascript like`ish.

Can we mix both?

Definitely you can mix source files in both OCaml and Reason, if that’s your question.
However, if you don’t have a baby duck syndrome for JS, I’m strongly recommend you to go with OCaml: Reason’s syntax is not very stable - authors can’t even decide whether to use ML-like or C-like style for a function application; see this thread.
OCaml syntax have it’s own drawbacks; but that’s not much a problem when you get used to it.

1 Like

Hey @ShalokShalom! As @Alex said the answer is yes, Reason is just syntax but is 100% ocaml under-the-hood.

Since you’re new to OCaml / Reason, I’d recommend not checking out Reason since, as @Alex said, it is in flux, moving to a more C-like syntax. Learn more about OCaml in the meantime since all of those concept are applicable to Reason, and wait for the new syntax to fully land (it’s merged in master but we’re still polishing it).

1 Like

I am someone who prefers to use well designed systems, that is why I spend weeks on evaluation for a programming language and that is why I write now on this topic.

I mean to mix both syntaxes, like here.

Reason does some nice changes and we can reverse that ones which feel inconvenient in order to create a new syntax which combines the ML-like look and feel with the usability improvements of Facebook.

Thanks a lot all together :slight_smile:

There have been some PRs to clean up some of the trickier parts of the OCaml syntax, including these two:

Getting a syntax change in is hard though, for arguably good reasons.

1 Like

I think this is very subjective, since I do not think that the Reason alternatives are better. They are maybe more familiar but some things are just as arbitrary or even more as in OCaml itself.

1 Like

Thanks a lot.

I read them and while these issues are of course relevant to the topic, are the issues which I mention above and below untouched by them so far as I can see.

Yes, it is subjective and that this subjective difference is important, is objective.

Plus: This and this and this seems like an objective improvement at all, while i prefer code with less symbols and Reason adds {} to the local scope, so there are again and again benefits on both sides for me.

Remind that I am a beginner, so I like to intelligible something that may stay for decades in my brain. So, this post is about creating a syntax for beginners, based on a mixture of that ones of OCaml and Reason.

From my point of view the only issue with OCaml syntax is with parametric type. I would prefer a functionnal syntax in curry-style like in Reason, but I do not like the way Reason manage tuple : a cartesian product is not a tuple, but a tuple is a inhabitant of a cartesian product. So, I would prefer : list (int * int) to express a list of pair of int.

According to A Brief, Incomplete, and Mostly Wrong History of Programming Languages :

1936 - Alonzo Church also invents every language that will ever be but does it better. His lambda calculus is ignored because it is insufficiently C-like. This criticism occurs in spite of the fact that C has not yet been invented.

and ML syntax is just a great syntaxic sugar around lamda-calculus. Reason is just an ugly C-like syntax. :stuck_out_tongue:


I have nothing against the ML-style, the thing is that there are issues, who get ignored by people in this community.

It’s not ignored. You just can’t do anything about it without breaking backwards compatibility.

1 Like

You can translate code between Reason and OCaml with refmt, there is even a translator for the web:

1 Like

I’ve been looking forward to using Reason’s tools to create a new OCaml syntax. I think it’ll take a lot of effort to get people to agree on what should be done though, and the work should be conservative in nature: don’t change things unless there’s a good reason to do so. What we don’t want is 100 different syntaxes causing major fractures in the community.


Quite the opposite: This conservative nature is the very reason, why these issues are still there, after 10, 20 years of development.

Why do you think, is it important that we all agree on one syntax?

Do we use one uniform language as well?

There are tools, like the mentioned refmt, who help us to translate the code back and forth.

So, we can use custom syntax sets for everyone and convert them automagically into the standard set.

A lot of people seem to have very difference preferences about which syntax should get used.
So why not serve them all?

I suggest to provide a solution that enables us to decide by our self.

This provides even the chance to translate keywords into other mother languages.

The real hurdle which I see, is that the OCaml community is obviously predominantly conservative and seems to be afraid about changes to things they identify with.

Even when these changes are without any force for them at all, its completely optional about what we are talking here.

As this thread discovers, act the overweight amount of people here until with obviously low interest about the introduction of new functionality and new developers, since they assume things about - in this case - Reason, without even checking the sources and this let me assume again, that there is prejudgment in play; which is counterproductive in each scientific field… :wink:

Much of the success of a programming language comes from the fact that it has a unified syntax that everyone can understand. If I need to study a new syntax every time I want to read/contribute to a library in OCaml, the language will become extremely unattractive. As a demonstration of this, look at the blowback Scala is suffering due the fact that it offers too much syntax flexibility – every library is a new DSL, making it extremely hard to learn to use new libraries. I experienced the same problem in Haskell.


You can offer an unified syntax.

So you just prove my point:

You did not even read my lines.

Perhaps your lines did not communicate as clearly or completely as you’d hoped? Communication is tough in general. Effective and productive communication requires charitable interpretation and patience on all sides. Dismissing opposing points with accusations of laziness, inattention, or prejudice can easily derail and shut down channels of communication. I urge caution, care, and humility here.

It is interesting to imagine collaborating on a project where people are using two different dialects to formulate and codify their thinking, but then combining a mechanical translation of these into a common standard (which I think is along the lines of what you are suggesting). I also have some reservations about this, though they are only feelings at this stage!

Regarding the syntax bike shed: I am personally inclined towards OCaml’s existing syntax over Reason’s changes in almost every case (with the exception of tuples and value constructors). The syntax changes I’d actually be interested in OCaml are towards more light weight modules and less ugly notations for ppx stuff.

However, ime, the history of programming language successes seems to indicate quite clearly that perfect/beautiful/elegant syntax is not requisite (and maybe not even helpful) for a widely used, long living, effective programming language! JavaScript is not victorious because it is prettier than, e.g, Io. Java is not widespread because it is syntactically more elegant or friendly than Haskell.

If one is only (or primarily) concerned with finding a perfect fit for their personal syntax preferences, then I guess any amount of syntax exploration and alteration and personalization makes sense! If one is mostly concerned with how to develop a coherent and ineffective community that is supported and stabilized by long-lasting and focused institutions, then these subtle syntactical tweaks may seem less pressing…

Personally, my interests tend to straddle both sides. However, if we’re going to focus energy on language design and development, I’d be much more interested in seeing something revolutionary like 1ML, Agda, concurrent OCaml, etc. get ready for prime-time in production that I am in seeing superficial tweaks to mostly solid and beautiful basis of OCaml.

This is largely a matter of personal taste, of course!


Thanks on your input.

I fully agree on this.

Nice said.

See? One more opinion.

The question why a programming language is successful in is a different one as the question why a programming language is successful.

What is successful in this terms?

Wide spread usage by the community? Then is OCaml not very successful yet.

Does this mean its bad?

So, the question is more, what makes sense. Within the meaning of what leads to our goals.

OCaml lives since decades, is healthy and effective, so its seems a nice and elegant syntax is also not a blocker for such a language. The causes for the success of Java and Javascript are clearly found on the business and PR side, as well as in historical reasons.

So, we can agree on the point that this is nice for newbies AND more experienced developers?

Thanks for sharing these ones, i will take a look on the first two now.
MC-OCaml is also one of the many reasons, why I love OCaml.

It shows to me, that OCaml is capable to adopt new features, even when they require fundamental changes.

I would love to see more of this in the public, A LOT of awesome features in OCaml are even more hidden as itself, which means a lot. :wink:

All those features count in, when you choose OCaml at all.
How can such a nice feature set count in, once the language design scares them away?

Well, I like to state that this is critic on an already very high level.

Same as Reason is a syntax for JS people, can we provide a syntax for programming newbies as well. And OCaml is already near to this just right now. ^-^

OCaml is obviously very much suitable for beginners, why does the community put such less spotlight on this aspect of the language?

OCaml provides an even more clutter free experience as traditional eduction languages, thanks to its awesome type inference, so it is very well suited from that point of view.

P.S: Ruby and Python are also popular since decades by providing an easy syntax and a beginner friendly community, so its possible to get popular by a nice sytnax :wink:

1 Like

One issue is documentation, both the integrated pieces like the official manual (which could, most likely, be converted into a form with automatic syntax conversion) and distributed pieces (SO, blog posts). The distributed parts can’t be controlled with the language so they’re likely to drift. The OCaml community already suffered through several years of pain around this when camlp4 was removed from the core language distribution and fell out of common use. It’s arguably still an issue since the first edition of Real World OCaml uses camlp4-based syntax extensions extensively.

I’m not arguing against syntax changes as the language develops - there are at least a few open PRs I’d love to see merged in some form to help clean up problematic areas of OCaml’s syntax. Leaving the syntax completely free-form, though, does splinter the community’s documentation. I don’t think that should be taken lightly.


I think such a page will fix it:

Camlp4 is a preprocessor while Reason use one.
This is a difference, since you can port the code with the click of a button in our case.

And yes, you can autotranslate Real World OCaml as well.

Name it an advanced feature for professionals, which somebody can use also in order to create such a newbie friendly syntax.

I love the style of F-sharp, which is indentation based, so as Python.
It is distraction free to read and write for me, compared to the other possible styles.

I am aware that this change is probably a challenging one.

Since this will be anyway a Reason fork, is there now an issue raised on its Github page.