2002-08-21 21:49:17 PDT
I've been studying the code and specification for the crush language for a few days, and i'm curious about a conflict that could arise in creating other languages that are link-compatable with the safe crush code (as in, they are bidirectional as mentioned in the info->crush->introduction section of the brix webpage). Identifiers in crush are defined in your specification as /[a-zA-Z][a-zA-Z_-]*/. The final '-' allows hyphen delimited identifiers, but seems to constrain languages that do not conform to pure prefix notation. For example, in crush one could write:
(+ first-variable second-variable)
assuming the identifiers were defined, this would add the variables. In a hypothetical language that allows infix operators, this translates to:
(first-variable + second-variable)
The problem arises in differentiating the hypens in the identifiers from the - operator of subtraction. I'm well aware that the language could simply require spaces between operators and operands, but that leaves a bad taste in my mouth. Is the benifit of a prettier syntax (rather than the standard _ delimiter) really worth crippling the syntax of other languages?
This really only occurs in the variable namespace (and perhaps functions, crush seems hazy about the distinction between normal and anonymous functions). Types and modules can obviously have hyphens, unless someone can explain a valid reason to subtract them.
Brand, I (think i) understand why you've chosen to include the hyphen in the identifier matching regexp, but as a prospective language coder for your operating system I ask you to reconsider in at least the function and variable namespaces. I think the consequences for other languages outweigh the advantages.
Feel free to lambaste my opinion :).