LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Blogs > Unpopular Positions: One Geek's Take
User Name
Password

Notices

A space to ponder, discuss, speculate, disagree, and learn.

Expected topics include:
  • Technology
  • Politics
  • Defense
  • Philosophy
  • Humanism and Transhumanism
  • The Future
Rate this Entry

ZACL Changes Afoot

Posted 07-17-2013 at 07:52 PM by ttk

Lately, when working on Zacl (Zacl's A Concurrency Language), I've been trying to implement a parser for the language with Lemon.

I've despised lex and yacc (and their successors, flex and bison) since 1988, and most of the other compiler-compilers out there looked to me like remakes of lex and yacc, using different implementation languages and different syntactic sugar. But not Lemon -- Lemon is different. It inverts the relationship between the lexer and the parser, and uses nice-looking syntax. It seemed like a good parser generator to try for Zacl.

Several months and many false starts later, I've decided that I despise Lemon too, and rather than working on the parser I've taken to writing some documentation, developing bits of the run-time environment, and complaining to my friends that Lemon just wasn't working for me.

My good friend Phoner mentioned in an offhand sort of way that some recent language implementations use hand-written parsers, rather than parser generators, but I didn't think much of it. Parser generators were The Way Things Were Done, always had been, and I'd be damned if I didn't do right by Zacl and implement it with a parser generator, too.

His comment stuck in my head, though, and a few days ago I started poking around. Ruby and Go use a parser-generator (bison), but Python does not, Perl does not (of course!), Lua does not, and neither does Dart. Even GCC's C front-end switched some years ago from flex/bison to a hand-written parser!

Apparently, Things Have Changed!

So, I scrapped my Lemon scripts and gave serious thought to writing a parser by hand.

It's been a remarkably liberating experience. Not only is it easier to think and plan about the parser, but it also freed me up to adjust the Zacl language specification. I'd made some decisions before which made parsing the language problematic, mostly to make the language more familiar to Python and Perl programmers. Those proved difficult to resolve at compile-time.

One of the objectives of Zacl is to move more processing overhead from run-time to compile-time while providing as many features of a dynamic programming language as feasible. Python and Perl are very dynamic languages, so it's not surprising that some of their concepts are simply incompatible with Zacl's objectives.

Since I was unburdened by any existing code which would need to be changed if I modified the language spec, I simply made the changes, and the language is IMO better off for it.

It's good that this change happened now rather than later, because I am finally in the process of exposing the Zacl project to the world as a GitHub project, the better to collaborate with folks who (surprisingly) want to make it a team effort.

There's not much there, yet, just a README.md and a single page in the wiki, but it's a start. I'll be transferring a few files over to the repo, and start using the wiki to write documentation and fiddle with the language specification instead of notebooks or text files on my laptop.

I'm ponderous and cautious by nature, so the process of exposing everything I have (that's worth exposing) will be long and sporadic.

A word on Zacl name capitalization: "ZACL" is correct. So are "Zacl" and "zacl". So is "ZaCL", if you prefer. I'm not big on setting rules.

Similarly, the right way to pronounce it is any way you can make yourself understood. I personally pronounce it like "Grackle", with a "Z" instead of the "Gr", but will not fault anyone for any reasonable pronunciation.
Posted in Technology
Views 322 Comments 0
« Prev     Main     Next »
Total Comments 0

Comments

 

  



All times are GMT -5. The time now is 04:13 PM.

Main Menu

My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration