2008/8/26 Allison Randal <[EMAIL PROTECTED]>: >> 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.
I'll go now for something like #IF(key1|key2&(key3&!key4)) #IFNOT(key1|key2&(key3&!key4)) And probably a shortcut for the negative else clause, like #IF(cygwin): #ELSE: #+ and #- is lisp so I don't want to destroy #+ the syntax rules. #IF(): is quite short and easy to read. -- Reini Urban http://phpwiki.org/ http://murbreak.at/
