There are some cases where I use many interfaces (in fact a lot) but a lot of the AST is sub-typing (or sub-classing) as it naturally makes sense.
A BinaryOperstor has a LHS and RHS of type Expression. BinaryOperstor itself is a kind-of Expression. Hence it can nest itself with (1*1)+(2*1).
Examples like those are prevalent through TBS syntax of T (and all languages) and hence implementation wise it just made sense to model it using OOP like that.
Open to suggestions and critique!
Operator is a red flag... builtin logic should only apply to values, and values, specifically, that are based on the CPU's built in types
vertical bars | are generally used as either bitwise OR or as concatenation operators for cryptographic operations, for example
but there's some nasty ambiguity there... append(first, second...) is unambiguous
i'm not gonna say anything about inheritance just focus on the point of redefining operators
many languages now allow you to redifine any infix, postfix or prefix operation on many other types
this creates ambiguity in the mind of the programmer, what does this + mean? addition? concatenation? encapsulation?
the more i have to think about what a common operation means, the more likely i am to not understand what two variables with this operatior between them means, and that increases the risk that i'm going to miss a bug
Once it is parsed it (a binary operator) is parsed it becomes:
LHS (Expression)
RHS (Expression)
Operator (SymbolType)
So it is available as such at that point.
As for your semantic point of view. Well that is processed later during typechecking.
A binary operator is the most generic way to describe it.
You determine the meaning based on the operands. In many cases I have used my type coercion mechanism which, I believe, coerces to the left hand operand.
So it works out well.
Do let me know if I have missed the point. This discussion is useful to me.
redefining infix, postfix and prefix operators on anything other than value types is a bad game, as is macros - they make it so when reading the code you have to go through two things to remember instead of just one, and then spread that out to a whole project
i'd say the thing you missed is why make another language when there is already a pretty much perfect one?
for me, there is #bitcoin and then there is #golang and these are two things that really don't need to be changed without inordinately long processes of deliberation, testing and modeling
in fact, in both cases i am of the opinion that several things could be removed and nothing of value would be lost
i am warming up to type parameters though, they have a use in reducing the amount of casting between basically identical types (eg int and int64)
Type parameters. As in meta programming?
golang's "generics" are really just a logical extension of duck typing... if it can be inferred, then it is permitted if the type parameter specifies it
although i don't know yet what the ~ means in them yet, didn't read that in the docs yet but i've seen it in an "x" package
In D we have full blown metaprogramming. I don't use it all too heavily except in a few projects like serializers etc.
But it is great. I can write code that writes code.
I'm a compiler man, it's my craft.
So of course I would make my own language as I want to write in it.
yeah, it's a bit of a search for the holy grail... i can't deny i don't think about it... was one of the first things i did when i got my hands on a c compiler was to play with bison and yacc
