Dave Herman: > I can imagine plenty of other such operators. Imagine an OO language > with a "message send" operator that quotes the name of the message: > x <- foo(a, b, c)
Sure, but that's not a problem. Sweet-expressions use a pattern to determine if something is an infix operator, which is basically "it only has punctuation". So <- would ALREADY be recognized as an infix operator, as would ->, =, /=, <=, +, *, /, and so on. (Of course, you have to USE it as an infix operator - it has to be in position 2 without an infix operator being in position 1). I just intend to tweak the pattern so that "and" and "or" are special cases - they are text strings that ARE infix operators. In my (lengthy) paper I discuss the pros and cons of predefining what is an operator, vs. requiring users to state what the operators are. I'm trying to define a single general-purpose syntax that's interpreted "the same" everywhere, so for my purposes, having a predefined method appears to be the better trade. The "nfx" macros separately discuss have slightly different goals and end up with the opposite trade - to support precedence you need to declare things anyway, so you may as well have declarations for infix operators. It's interesting that the different approaches (define a macro vs. redefine the reader) end up with so many other differing choices. > or the infix dot-operator for selecting record fields, which doesn't > just take two expressions. Well, "." already has a special meaning in Lisps (at least Scheme and Common Lisp) - pair creation. E.G., '(a . b) is a pair with a car of 'a, and a cdr of 'b. I think using "." for something quite different would be confusing (let me know if that's not what you mean). I understand the desire for a special shortcut for mapping/field access. Almost all languages - from Fortran down to C, Java, Python, and Perl have such syntax shortcuts, because they're such common operations. I'm currently thinking about allowing syntax like a[b] for mapping/field access. Using the syntax a[b] to access a map is well-established in computer languages. In sweet-expressions a prefixed entry produces a DIFFERENT result for other syntax, so this is reasonable enough; i.e., name(stuff) converts to (name stuff), while (stuff) becomes (stuff). The challenge, interestingly enough, is what to map a[b] into. Presumably it would become the s-expression: (bracketaccess a b) One problem: I don't know what the "correct" name should be instead of bracketaccess. (You could then define a macro for "bracketaccess"). One positive: I get NO hits for "bracketaccess" that are Lisp-related, so this is possibly a relatively safe word to use. --- David A. Wheeler
