Forest, a multi-syntax functional language that compiles to WebAssembly

I find the design principles interesting. We might talk a lot about syntax abstraction, but I feel like that's not even the most interesting idea (it's very likely that many people who thought about making languages thought about it).

There are a few trends I find interesting, though. Programming languages are pretty tricky. You need to think about style and readability, performance and optimization, scalability and maintainability, data types and abstractions, algorithms and data transformations, parallelism and concurrency, etc. It seems to me like we have been introducing systems that progressively try to modularize and isolate those issues, sometimes completely hidding them from us. Syntax abstraction shouldn't be so surprising if we follow this idea. We got garbage collection, most optimization is done by compilers, we got dynamic typing, endless discussion about models for data representation, even visual languages, etc. The idea that programming languages shouldn't be limited to text in a single source file is very important in my opinion. I often envision future programming as "powerful IDEs" (and I never use IDEs nowadays) that can represent different properties/aspects of programs/code in different ways/views, isolating them or showing relationships/interaction between them. The complete opposite of what we see in movies, as always happens in reality, hahaha. Well, went a bit off-topic so I'll stop here.

https://isomorf.io/#!/syntax-picker/tours-ideas

Would love to read more about the immutable data structures it supports. Rich Hickey has some great talks on efficient immutability in Clojure.

I really believe we're going to see a lot more new languages targeting web assembly. I wish it supported a standard, pluggable garbage collection system that could be easily adopted.

The main idea is to represent languages as a graph of 'language constructs' and individual programs as paths through some language graph. That path is the 'model' which an editor or compiler/interpreter would operate on—but in the case of the editor, since the program model has no connection to syntax, you can configure how it's rendered on a per-user basis (or use it to experiment with new language UI concepts, etc.).

Here's a write-up with illustrations: http://westoncb.blogspot.com/2015/06/how-to-make-view-indepe...

I've had this on the back burner for a while now, waiting for the write moment to try building out a proof-of-concept version—but if someone could point out some kind of critical flaw in it and prevent me from wasting so much time, that'd be awesome :)

With the exception of s-expressions (too many parentheses) and mandatory/significant whitespace, most people don't seem to care too much about syntax, IME. Semantics are much more important.

Interesting project, I like the emphasis on immutable data and pattern matching.

2. We're definitely getting closer to the era of language swappability, where language X transpiles to language Y, language Y compiles to language X, and strict code formatters clamp down on corner cases. I think it's great and welcome, but I would expect a side effect of this to be that more "free" languages pop up that allow programmers to be a little looser in their implementations.

They think it will help adoption? But surely it also hinders it by fragmenting code examples in the wild (Stack Overflow, docs, blogs etc) into different syntax populations?

https://reasonml.github.io/

`FooError on line 111` suddenly becomes a lot less meaningful... I suppose that's what the canonical representation is for, but having to map between the two seems like it would be at least somewhat annoying.