[antlr-interest] language design

[Sam Harwell]

While this is somewhat true of Java, it's really not true of C#. The
built-in primitive types in both languages (int, short, double, char,
bool) are passed by value in function calls and kept on the stack as
local variables. The process of boxing in both languages takes a
primitive type and wraps it as an object on the heap, as required for an
operation like the following. The process of unboxing (also shown)
converts it back to a primitive.

 

object o = 3;

int i = (int)o;

 

In Java, there are two severe limitations to the ability of primitives.
First, the language doesn't allow user-defined primitives, so there is
no concept of lightweight enums, aggregate data structures, or the
ability to create special struct based on an int that has special
meaning with no more overhead than the int itself (say for a special
application-specific type of bitfield, or distinguishing a
platform-width integer from a memory address/pointer stored in a
platform-width integer). Second, generics such as ArrayList<T> in Java
are only handled specially by the compiler. At runtime, the storage used
inside the list forces boxing/unboxing of values. Arrays of primitives
(like int[] a) are able to hold unboxed values, so they are lighter.

 

C# shows heavy advantages in several areas by hitting these issues
square on the head. First, enums are as lightweight as ints, so using
them is an encouraged, zero-overhead practice. Second, careful use of
structs, C#'s way of creating user-defined unboxed values, leads to
immense performance benefits in places like embedded computing, systems
programming, high-performance applications, and even cases like my
high-performance SlimLexer for ANTLR's C# port that operates 5x faster
than Lexer in 1/5 the memory (I sent an email to antlr-dev mailing list
about this). Third, when a generic type is instantiated at runtime with
a value type (like List<int>), the JIT actually produces code that
operates fully on unboxed values, in cases allowing performance rivaling
C++ templates. These advantages are one of the reasons I believe
Google's use of Java for the Android platform was an unacceptable
mistake, a failure to meet the fundamental requirements of their clients
as well as they could. It is the responsibility of development teams to
not make decisions like they did knowing full well it will result in a
crippled end-user experience.

 

Sam

 

From: antlr-interest-bounces at antlr.org
[mailto:antlr-interest-bounces at antlr.org] On Behalf Of Edwards, Waverly
Sent: Thursday, May 07, 2009 9:16 AM
To: 'antlr-interest at antlr.org'
Subject: [antlr-interest] language design

 

 

 

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.

 

 

The only example that comes to mind is something like this

 

[simple language]

 

Integer BirthYear

String showBirth

 

showBirth = "You were born in " + BirthYear.toString()

 

print display

 

 

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.

 

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.

 

 

Thank you,

 

 

Waverly.

 


______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090507/52b14a60/attachment.html