On Tuesday, 5 January 2016 at 16:10:21 UTC, Jason Jeffory wrote:
1. Grammar independence - People speak different languages and
perceive logic through different symbols. It is the nature of
life and knowledge.
I want to focus on that. If multiple developers need to work on
the same project, having different grammars is not a very good
idea. Consistency is important - we promote coding standards to
cover the parts not enforced by the grammar - so mixing the
different grammars in the same project is a huge no-no. Promoting
multiple grammars will be a disservice to programmers then, since
each project will have it's chosen grammar, and number of
projects each developer is comfortable working on will be
drastically reduced.
Of course, as already suggested in this thread, AST editors could
do that translation, and having me use a different grammar than
you will become as simple as my text editor highlighting keywords
in different colors than yours. Then again - if this will be the
case, using different grammars will also be about as meaningful
as having different color schemes...
However, using different grammars can have a different goal -
reducing the boundaries between libraries. If everyone use
different grammars of the same language, you won't have to give
up on or struggle with a cool library just because it's written
in a different language than the one you use.
This problem is currently addressed by platforms like Java and
.NET. Languages on these platforms are compiled into bytecode,
with an expressive enough format that allows any language on the
platform to use libraries written in other languages - without
the need to translate the library's interface to the client
language.
The main hurdle with these - which I believe your dream language
will have to face as well when it tries to support multiple
grammars - is supporting the many language-backed idioms that
modern languages use to make our code cleaner and safer.
Let's consider, for the Dispose
Pattern(https://en.wikipedia.org/wiki/Dispose_pattern). The
syntax in Java and in Python looks quite similar:
try (BufferedReader reader = new BufferedReader(new
FileReader(filename))) {
return reader.readLine();
}
with open(filename) as reader:
print(reader.readline())
So, since Python has a JVM version - Jython - you would expect to
be able to do this:
with BufferedReader(FileReader("chapter-tracker.sh")) as
reader:
print(reader.readline())
But no - you get an error:
AttributeError: 'java.io.BufferedReader' object has no
attribute '__exit__'
So, what happened? While the idioms look similar in Java and
Python, the semantics behind them are quite different. In Java,
`try (Foo foo = new Foo())` will simply call `foo.close()` when
the block is exited. In python, `with Foo() as foo:` will call
`__enter__()` on `Foo()`'s result, assign it's result to `foo`,
and when the block exists it call `__exit__(...)` on `Foo()`'s
result from back than(not on `foo`!)
To solve this, you'd have to define such idioms as part of the
platform, and thus all the languages(/grammars) could follow
them. But this comes with it's own price:
- The list of idioms you'd want to make official can become
quite large - making the interface between the platform and the
languages/grammars more complex, and therefore the implementation
of such languages more complex. This is something
platform/language designers usually try to avoid.
- Language/grammar designers will want to add new idioms to
their languages/grammars, but the process of adding a new idiom
to the platform will be quite long. This will give
language/grammar designers to just add their new idiom into their
own creation, without caring about consistency in the platform's
ecosystem.
So, like everything else in our profession - this is a matter of
tradeoffs.
