operator overloading not as useful as it could be

[loveencounterflow]

so i toyed around with the vector math example in readme section Working with Nodes, and my suspicion got vindicated—you're free to re-define an existing symbolic CS operator like * or +, or it's not getting to work. meaning you have a very small choice for symbolic operations and you will invariably shadow one of the (precious few) standard binary operators in your module. this, of course, is to be expected, as BC works on the CS AST, so all code must still comply with CS syntax.

IMHO one particular use case of macros is the ability to define locally-valid syntactical constructs so you can define your own DSLs. given that CS already allows function calls without brackets, defining your own unary and binary symbolic operators would appear the logical next step. this may be an unattainable goal within the current setup of CS's parsing, which (to my understanding) relies on an early lexing step. for more thoughts on this see jashkenas#2887 (comment)

[vanviegen]

BlackCoffee macros can only modify an AST that has already been fully lexed and parsed. In other words: only grammatically valid CoffeeScript code can be valid BlackCoffee code.

Of course it would be possible (but hard and error prone) to modify the lexer/parser rules during compilation. But I don't aspire to do that with BlackCoffee.