[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Prefix, not postfix

This page is part of the web mail archives of SRFI 88 from before July 7th, 2015. The new archives for SRFI 88 contain all messages, not just those from before July 7th, 2015.

David Van Horn wrote:
On Tue, 2006-04-11 at 15:51 -0700, Per Bothner wrote:
An alternative worth considering is an infix syntax.  For example:

(button color="red" font="Helvetica")

I.e. the syntax is:
This would be translated by the reader into (say):
   (make-association '<identifier> <expression>)


Unfortunately, this syntax does conflict with historical
<identifier> syntax in certain presumably-very-rare cases.

This conflict is not at all rare.  There are a dozen R5RS identifiers
such as string=? that would break under this particular infix syntax.

Only if "?" is a valid expression.  Using ? by itself as an identifier
is very rare.

Extending syntax has a tradeoff:
(1) Breaking some hitherto legal but ugly and/or rare programs.
(2) Using new characters.  Easy if we're willing to go beyond ASCII.
(3) Using uglier and/or more verbose constructions.

For almost anything we do, I can construct a program that will break.
This is true for almost any new syntax, even if we don't change the
reader syntax, but only add new macros.

Now I suspect <identifier>=<expression> is not a very good choice.
The problem isn't conflicts with existing code, but defining
the reader syntax such that we minimize conflicts with existing code
may be quite ugly.  Most onbiously we'd have to prohibit ? by itself
as an identifier, but allow it as a final character. That appears to
fix the R5RS conflicts, but there are likely others.

The key suggestion isn't using =.  The point we don't need a new keyword
type if we instead define a reader syntax that translates into an
"association object".

Using association objects has some advantages.  Consider:
  (f a k1: b)
Is k1 a parameter keyword?  Only if a does *not* evaluate to a keyword!
	--Per Bothner
per@bothner.com   http://per.bothner.com/