[antlr-interest] language design

Randall R Schulz rschulz at sonic.net
Thu May 7 07:38:15 PDT 2009


On Thursday May 7 2009, Edwards, Waverly wrote:
> This question is not directly aimed at ANTLR but towards language
> design. If someone wouldn't mind responding or directing me towards
> the answer to why would I want a primitive type to be treated as an
> object.  In Java and C#, primitive types are treated as objects.  It
> seems to me that by doing so, you would increase the overhead of
> converting values and thus it would become a detriment to the
> language.  It appears that you might want this to part of your
> language to make it easier for the user/developer.

I know nothing about C#, but Java's five integer types, two 
floating-point types and its boolean type are implemented by 
machine-level entities, not objects. There are counterparts for each of 
them (the so-called "boxed" primitive types).

Scala makes all of these types objects (they call them Value Types) but 
wherever possible generates JVM bytecode to use the primitive types and 
save the overhead of boxing and unboxing.


> ...
>
>
> I don't see the benefit of making a primitive type an object other
> than to make it easier to perform operations the user can perform in
> other ways with less overhead.   I can make more of an argument for
> making composite types as objects.

The benefit is substantial. Having entities in the type system that are 
exceptions to most of the rules about what user-defined types can do 
gets in the way of many things. You cannot, e.g., use an "int" as a key 
or value in a map data structure. Examples abound.

Furthermore, the cost of using boxed types is probably not as big as 
your intuition is telling you. Depending, of course, on the nature of 
the program. It would be hard to do a competitive FFT using boxed 
floating-point types, I suspect.


> I have a couple of books on language design but none of them address
> this issue. I believe this would fall under boxing and unboxing.  If
> someone could direct me towards a good reason to implement this in a
> language, it would be very much appreciated.

Are you designing a language? If so, may I recommend that you don't? The 
world does not need another language that is naively designed. I don't 
mean to be rude, but this phenomenon is responsible for a lot of poorly 
designed languages coming into widespread use, and the consequences are 
real and negative.

If you really want to work in programming language design, then learn 
where the frontiers really are and concentrate your efforts there. 
Unless you're some kind of genius, nothing you think up as an offhand 
good idea is likely to be a real contribution to the field.


Again, I don't mean to offend, just to guide you towards learning the 
field of programming languages before trying to contribute innovations 
to it.


> Thank you,
>
>
> Waverly.


Randall Schulz


More information about the antlr-interest mailing list