[antlr-interest] Type discovery for operator overloading?

C. Mundi cmundi at gmail.com
Sat Jun 14 10:38:18 PDT 2008


I suspect I will come to see the truth in what you write -- that it is
merely a matter of shifting the complexity, not changing the overall
complexity -- when I get my head fully wrapped around it.  That will come
with time, I suppose.  Thanks for putting me on the path.

c. mundi


On Fri, Jun 13, 2008 at 9:03 PM, Gavin Lambert <antlr at mirality.co.nz> wrote:

> At 15:37 14/06/2008, C. Mundi wrote:
>
>> You're quite right: I entirely neglected to mention that my little
>> language is dynamically typed.  That was an important bit to leave out.
>>  Dynamic typing was one of my preliminary user requirements leading me down
>> this rabbit hole.  But as I begin to appreciate some of the implications, I
>> wonder if the runtime cleverness we originally sought is worth the added
>> complexity.  Of course, only my users can answer that.  Your reply has
>> helped greatly to sharpen my thinking on the subject.  Thank you.
>>
>
> I'm not sure "added complexity" is quite right; it's just putting the
> complexity at a different point.  For a statically-typed language you can
> make all the type decisions at "compile time" (ie. within ANTLR) -- or defer
> them until runtime if you prefer.  For a dynamically-typed language then you
> have to make the type decisions at runtime.  They're still the same
> decisions, though.
>
> It's probably marginally easier to implement when your host language and
> custom language are both either static- or dynamic-typed; if there's a
> mismatch, you have to do a bit more work, but it's usually not too
> complicated.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080614/2ada602c/attachment.html 


More information about the antlr-interest mailing list