Ask HN: Does the design of a programming language includes writing its compiler?

3 points by basicscholar ↗ HN
Or is topic only related to specifying grammars? Note: I'm novice don't crucify me. :)

4 comments

[ 2.8 ms ] story [ 23.6 ms ] thread
The design does not /have/ to involve writing a compiler. For instance, the X3J13 committee designed the ANSI Common Lisp standard, but left writing implementations up to third parties. On the other hand, the team of Julia language developers both design and write the compiler.

I guess it depends on your motivations for creating the language. Programmers will often design a language and write the compiler/interpreter themselves as a learning experience.

https://en.wikipedia.org/wiki/X3J13

http://julialang.org/

Writing an interpreter or compiler isn't necessary, but can help because it allows people to write real programs in the language, and that can tell you whether that great idea that you put in your grammar actually has value in the real world.

And you do need more than a grammar; you also have to specify semantics. For example the grammar may state that you can write "x = y" at some place in your language, but what what does it mean?

Does it copy y to x, copy x to y, make x and y refer to the same object (with choices of x, y, a new thing that has the same value as x, etc.), test whether x and y are the same object, have the same value, ascertain that x and y have the same value, ensures that they have the same value by replacing their values by their average, or is y an implicit string, and do you have to write `y or $y to reference variables in expressions? Is there any side effect? For example, does the new value of x get printed to the console by default?

(Some of the options I give are 'unconventional', but you have to specify your choice)

It's often beneficial to the language for its author(s) to write the compiler as well. Without doing this, there's a tendency to cram every feature imaginable into the language (see eg. ANSI Common Lisp, Algol 68, PL/1), which tends to make it too difficult for anyone to learn or program with. The need to write a working implementation is a forcing function that keeps the language design simple and ensures that the language designer deal with any unintended interactions between features.
Common Lisp is not the all-feature Lisp. It's basically a slightly simplified and improved version of Maclisp successor projects (NIL, S-1 Lisp, Lisp Machine Lisp / Zetalisp, Spice Lisp). Thus Common Lisp basically of similar complexity of prior Lisps.

Common Lisp does inherit very very little from other Lisps like Interlisp, Standard Lisp, etc.

Common Lisp was designed by implementors. If it is 'hard' to program in it, it probably is more BECAUSE it was developed by implementors:

   Gabriel: NIL (New Implementation of Lisp) -> Lucid Common Lisp
   Steele: NIL 
   Moon: Lisp Machine Lisp -> Symbolics CL
   Weinreb: Lisp Machine Lisp -> Symbolics CL
   Fahlman: Spice Lisp -> CMUCL
Even the later ANSI Common Lisp was designed with implementations of its new features. For example CLOS was designed mostly by people from Xerox PARC. CLOS was at the same time implemented by them in a portable implementation called PCL, where the designed was explored and feedback was assembled from a group of users. The very people who wrote the spec for CLOS and a book about it, they also implemented it.