In LISP, the historical style was to permit fairly generous punctuation
identifiers, and we adopted this in BitC. Now that we are pulling
together the block syntax, this is coming back to haunt us a bit.
Problem 1: cross-syntax compatibility
In the S-expression syntax, we currently accept any of:
!$%&*+-/<>[EMAIL PROTECTED]
in *any* position of an identifier. The problem is that we would like
the legal identifier space in the block syntax to match the legal
identifier space in the s-expression syntax. Proposal:
! + - & ~ are single-character prefix operators in block
syntax
PROPOSAL:
!, &, ~ are only used in unary contexts.
If we disallow them as the *first* character
in an identifier, we can keep them elsewhere.
-, + are also infix operators. See below.
< > = & | + - * / % are the first character of some infix operator
in the block syntax
CHOICES:
1. disallow all of these in s-expr syntax
identifiers
2. Require ALL binary operators to be surrounded
by white space, parens, or something that
separates them from identifiers, and disallow
them in the leading position of an identifier
The main issue here is that hyphens are very popular
in LISP-style identifiers, so giving them up may be painful.
I personally prefer white space around all operators, but I
hesitate to make this a hard requirement.
$ @ _ ? have no current use in the block syntax,
so there is no problem with them.
Problem 2: Punctuation vs. Methods
Nearly all of the non-syntax punctuations are type class methods. In
order to make them extensible we want to be able to mention them in type
class instances, but in the block syntax we cannot accept these symbols
in identifiers, which makes them syntactically illegal in an instance
definition.
PROPOSAL: The compiler will treat punctuation that names functions as a
convenience syntax for functions that have legal names. The front end
will simply rewrite them, e.g.:
x + y
into
add(x, y)
and the meaning of "+" can then be augmented by defining a new instance
for the "add" method.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
