What I learned at the Emerging Languages Camp(journal.stuffwithstuff.com)
journal.stuffwithstuff.com
What I learned at the Emerging Languages Camp
http://journal.stuffwithstuff.com/2010/07/23/what-i-learned-at-the-emerging-languages-camp/
4 comments
The author's talk on Finch was indeed awesome. He was very funny and modest and self-deprecating, but it was obvious to everyone that he was really smart. And his talk had some of the most quotable bits in the whole conference.
"I'm writing a recursive descent parser by hand because I keep it real." LOL
His listings of the things his language couldn't do were hilarious too.
In response to a question from the audience, he discussed how he designed a programming language for the first time, which was really edifying and an interesting discussion of the mental journey. His answer was really good and I can't do it justice, but it talked about how he solved the problems by working in little stages. He knew that he could break up a text file into tokens, and that's how he built a lexer. Next, he realized that a parser was a lot like a lexer, and recognized groups of tokens, so he could build a parser. So he then had a tree, and he found that he could walk that tree. As he walked the tree, he realized he could emit bytecode. It was a really good description, and better than any single lecture in an entire semester of my college Compiler Construction class.
The fact that the author didn't even know he was going to be able to speak until the day of the presentation, and came up with a very polished and professional and engaging presentation says volumes about his ability. I think everyone really enjoyed his talk, and it really had a sense of joy and fun and discovery about it. And it was funny as hell. There is no doubt that we'll be seeing much more from him.
"I'm writing a recursive descent parser by hand because I keep it real." LOL
His listings of the things his language couldn't do were hilarious too.
In response to a question from the audience, he discussed how he designed a programming language for the first time, which was really edifying and an interesting discussion of the mental journey. His answer was really good and I can't do it justice, but it talked about how he solved the problems by working in little stages. He knew that he could break up a text file into tokens, and that's how he built a lexer. Next, he realized that a parser was a lot like a lexer, and recognized groups of tokens, so he could build a parser. So he then had a tree, and he found that he could walk that tree. As he walked the tree, he realized he could emit bytecode. It was a really good description, and better than any single lecture in an entire semester of my college Compiler Construction class.
The fact that the author didn't even know he was going to be able to speak until the day of the presentation, and came up with a very polished and professional and engaging presentation says volumes about his ability. I think everyone really enjoyed his talk, and it really had a sense of joy and fun and discovery about it. And it was funny as hell. There is no doubt that we'll be seeing much more from him.
> the language implementation is incredibly easy to read and understand.
Thanks! After wading through an SML compiler whose author apparently thought single-letter variables and no documentation was perfectly fine in a language that doesn't even have fucking type annotations, I figured the least I could do to advance the state of the art was make the code legible.
Thanks! After wading through an SML compiler whose author apparently thought single-letter variables and no documentation was perfectly fine in a language that doesn't even have fucking type annotations, I figured the least I could do to advance the state of the art was make the code legible.
Good article, but I have to nitpick here:
Any well-versed programming language person can tell you about both recursive-descent parsers and generated parsers. They’ll also tell that generated parsers are the “right” way to do that.
Most of the time that advice will save you from wasted effort, but sometimes I think it keeps people from going down paths that may actually be fruitful. Sometimes the thing that everyone knows is true isn’t. (For example, every language I know of with a lot of real-world users actually does use a hand-written parser.)
Recursive descent parsers are good when 1) you have a simple grammar and 2) you want fewer dependencies. Most lisps have hand-written recursive descent parsers because lisp grammar is easy.
Also, MRI ruby (aka CRuby1.8) uses a generated parser.
Any well-versed programming language person can tell you about both recursive-descent parsers and generated parsers. They’ll also tell that generated parsers are the “right” way to do that.
Most of the time that advice will save you from wasted effort, but sometimes I think it keeps people from going down paths that may actually be fruitful. Sometimes the thing that everyone knows is true isn’t. (For example, every language I know of with a lot of real-world users actually does use a hand-written parser.)
Recursive descent parsers are good when 1) you have a simple grammar and 2) you want fewer dependencies. Most lisps have hand-written recursive descent parsers because lisp grammar is easy.
Also, MRI ruby (aka CRuby1.8) uses a generated parser.
False dilemma as there are parsing frameworks that use top down grammars (namely PEGs and their derivatives).
Grammars written in these languages very closely resemble the structure of hand written recursive descent parsers, unlike generative grammars, but also are amenable to automatic generation of efficient parsers (namely packrat parsers, but in practice even just one or two entries of memorization at each production is performant).
MRI's parser is a disaster. It makes sense given the context of when it was written, but the language would be free of some syntactic warts if they'd moved to something with more lookahead some time ago. The opaqueness of the parser grammar is repeatedly mentioned as a limit on useful contribution to the language.
Grammars written in these languages very closely resemble the structure of hand written recursive descent parsers, unlike generative grammars, but also are amenable to automatic generation of efficient parsers (namely packrat parsers, but in practice even just one or two entries of memorization at each production is performant).
MRI's parser is a disaster. It makes sense given the context of when it was written, but the language would be free of some syntactic warts if they'd moved to something with more lookahead some time ago. The opaqueness of the parser grammar is repeatedly mentioned as a limit on useful contribution to the language.
This is from hazy memory, but I stated that because I think GCC, Clang, MS's C# compiler, and javac all use hand-rolled parsers.
I think the recursive descent ones are also worth favoring when you want to have more informative error messages
Yes, I like writing recursive descent parsers but I don't know of any in "industrial" use, beside the lisp parser you just mentioned.
I'd like to know if there are more.
I'd like to know if there are more.
LLVM's clang uses a recursive-descent parser to parse C, ObjC, and C++ (http://clang.llvm.org/features.html#unifiedparser).
Clang is the "C Language Family Front-end", which means we intend to support the most popular members of the C family. We are convinced that the right parsing technology for this class of languages is a hand-built recursive-descent parser. Because it is plain C++ code, recursive descent makes it very easy for new developers to understand the code, it easily supports ad-hoc rules and other strange hacks required by C/C++, and makes it straight-forward to implement excellent diagnostics and error recovery.
Clang is the "C Language Family Front-end", which means we intend to support the most popular members of the C family. We are convinced that the right parsing technology for this class of languages is a hand-built recursive-descent parser. Because it is plain C++ code, recursive descent makes it very easy for new developers to understand the code, it easily supports ad-hoc rules and other strange hacks required by C/C++, and makes it straight-forward to implement excellent diagnostics and error recovery.
Industries using a recursive descent parser: http://www.edg.com/index.php?location=customers_oc
Glad I read this, because I learned about Frink: http://futureboy.homeip.net/frinkdocs/ and the FAQ: http://futureboy.homeip.net/frinkdocs/faq.html
This guy knows units of measurement.
This guy knows units of measurement.
His presentation was a pleasure to watch. I'd seen the pitch for frink in a video some time ago, but he's a charismatic speaker that keeps your attention even if you're roughly familiar with the material.
During the QA portion someone gave him a "gotcha" question only to have the tables turned when it was made clear the speaker new _far_ _far_ more about standards and units of measurement than anyone in that room, city and possibly state.
During the QA portion someone gave him a "gotcha" question only to have the tables turned when it was made clear the speaker new _far_ _far_ more about standards and units of measurement than anyone in that room, city and possibly state.
I would prefer a conference about emerging features in languages, since many languages only differs in superficial aspects. Is better to located what new features are needed.
There were a number of talks in that vein. Rich Hickey's talk about his experimental "pod" feature in Clojure for safe scoped mutation, Joe Pamer's talk about making F# suitable as a first-class .NET language, and Jonathan Shapiro's talk about the correctness constraints guiding BitC's design all focused more on problem domains and the features necessary to fill those domains than superficial language features.
I'd estimate that only half of the languages presented were of the sort that differ only in minor aspects. Several of the languages presented were _far_ outside the mainstream, particularly the two visual languages which were surprisingly practical.
On the whole I'd say factor was likely the most unconventional language besides those mentioned above. The breadth of libraries they have built while being so iconoclast is impressive.
On the whole I'd say factor was likely the most unconventional language besides those mentioned above. The breadth of libraries they have built while being so iconoclast is impressive.
For someone interested in programming language design or implementation, Emerging Languages Camp had a lot to offer. It received universal praise from everyone I talked to.