On Mon, 25 Aug 2008, Reini Urban wrote:
To clarify my bold statement:
The ALGOL-like syntax is not "sane" because,
* it is hard to parse,

Not actually true. It's just different to parse. And, in general Parrot optimizes for making code easy to *read* even if it is slightly harder to parse. We have the most powerful parsing tools on the planet at our disposal, there's no reason to push the difficult work on the code maintainers.

* it forbids our keywords AND, NOT and OR as config_hash keys
  and platform names.

This isn't an onerous restriction.

With lisp syntax there's a clear distinction
  between operator and arguments, with mixed arg op arg syntax
  it is not clear and as hard to understand as spoken language.

If your background is lisp-like syntax, then yes it's easy to understand. But our primary target audience for Parrot is not people with a background in Lisp, it's people with a background in modern dynamic languages like Lua, Perl, PHP, Python, and Ruby. All of which are more familiar with infix notation.

Andy Dougherty wrote:
What we did in perl5's build system was to recognize that we didn't have to invent or borrow any new syntax at all. The languages we were using to write the Makefiles (namely /bin/sh and perl) already had sophisticated interpolation and conditional syntax capabilities. We used here-documents and interpolation instead of macro substitution. We used the language's built-in conditional and flow control syntax to express complex ideas.

This particular chunk of syntax is indeed parsed by a Perl preprocessor for the Makefile. But, that doesn't necessarily mean that we want to directly eval/interpolate Perl conditional syntax. For one thing, it won't always be parsed by a Perl preprocessor, it'll eventually be parsed by a PGE-based preprocessor.

Alternatively, we could use Makefile conditionals, but those are cumbersome. And, this particular pair of preprocessor directives give us a way to block out lines during preprocessing, so that 'make' never has to parse them at all.

Picking any one HLL to mimic is problematic in our multi-lingual environment. But, we definitely want to pick syntax that will seem familiar to our primary HLL targets.

Allison

Reply via email to