The Artima Developer Community
Sponsored Link

Weblogs Forum
Primitive Types ... In a Library?!

5 replies on 1 page. Most recent reply: Oct 27, 2004 12:50 PM by Christopher Diggins

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Primitive Types ... In a Library?! (View in Weblogs)
Posted: Oct 26, 2004 3:19 PM
Reply to this message Reply
Summary
Possibly my favourite feature of Heron, and what sets it apart from C++/Java/C# style languages is that primitives are defined in a library, not by the language. Why other languages don't do this is beyond me.
Advertisement
In many modern imperative languages: C++/Java/C# etc. primitives are predefined and are not even objects. They have no methods, they follow special conversion rules, they have predefined operators, they can not be inherited from. Sometimes they have separate object counterparts to the primitive types which requires a rather unpleasant boxing/unboxing mechanism.

Heron changes all that.

Knowing exactly what a programmer will want in the general case is impossible, so by locking in a particular behaviour or representation of the primitives is needlessly limiting. In fact often the choice of a particular language is done purely because of the primitives available. This just doesn't make sense in today's age. A Heron primitive library can be tuned towards catching bugs, or towards performance, or even towards reducing verbosity.

This catches people examining Heron off-guard because typically when evaluating a language they look at the primitives available to them. There is no reason to reject Heron because of the representation of a string, or inaccurate floating point characteristics. The library is comletely open-source and transparent, if you don't like some part then rewriting it is trivial! For instance you might not like that the primitive names start with capital letters, or you might not like the fact that the standard library initializes the primitives. Well then by all means, write your own version. If you share it with me, maybe I'll even use it as part of my next release.

For more information, download the latest Heron standard library and have a read through at: http://www.heron-language.com/downloads.html.


Steve Love

Posts: 20
Nickname: essennell
Registered: Sep, 2004

Re: Primitive Types ... In a Library?! Posted: Oct 27, 2004 2:33 AM
Reply to this message Reply
Not sure I agree with you that simple numeric primitives should be in a library. I don't honestly feel the need to inherit from "int", in C++ or C#, or to change its characteristics.

I also think that most programmers choose a language based on what libraries are available for it - what it allows them to *do*. I prefer writing in C++ to any other language because of the rich set of libraries available, making me more productive, allowing me to get non-trivial jobs done simply and coherently.

If I want an integral numerical type with behaviour that differs from the built-in, I can create one - along with operators and conversion rules of my own - that exhibits the behaviour (debugging, performance, reduced verbosity) I want.

The C++ standard string is a library type (OK not a great example, but there you go) but I don't think strings count as "primitives". A proper built-in string for the C++ *language* might be an improvement - the reverse of what you suggest.

All that said I've not looked at Heron in any detail, just kind of stumbled over this blog! So, I'll go have a look, then shall I?
:-)

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: Primitive Types ... In a Library?! Posted: Oct 27, 2004 5:13 AM
Reply to this message Reply
It's nothing to be excited about. If you dare to look outside C++/Java/C#, usually "primitives" are not different from other types with respect to the type system, argument passing, semantics of assignment, implicit conversions etc. Look at Haskell, OCaml, Python, Ruby, Smalltalk.

They are special only in that their physical storage layout is unusual (e.g. they don't consist of references to other objects as most objects do), and that there is a syntax of literals which produces values of these types. Same as in Heron wrt. the types with underscores.

It doesn't matter in practice. As long as it behaves consistently, it doesn't matter how it's implemented. I don't care whether Float is a primitive, or a wrapper for a primitive - the net effect is the same.

It matters though how a programmer can add "primitive" types implemented in another language, similar to your types with underscores but as an open set. For example let's say we are interfacing to the bzip2 compression library, and want to wrap the C struct of type bz_stream as an object in our language, call bzip2-specific methods implemented in C on it, and the library wrapping should ensure that it's closed automatically when we finish with the wrapper object. The C struct is not copyable in a meaningful way, it must have a constant address (this is easy to ensure if you malloc a storage for the struct and pass the pointer - you only need to know when to free it). How to wrap such type in Heron?

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Primitive Types ... In a Library?! Posted: Oct 27, 2004 11:44 AM
Reply to this message Reply
Hi Steve,

"If I want an integral numerical type with behaviour that differs from the built-in, I can create one - along with operators and conversion rules of my own - that exhibits the behaviour (debugging, performance, reduced verbosity) I want."

This functionality is available in C++, and is what I wanted to achieve in Heron but as the default in Heron. When primitives are objects then it is easier to define new custom low-level types with different properties. It is then possible to do things like create interface variables to the primitives, delegate interface implementations to the primitives, or inherit from the primitives. This might not directly be interesting to you as a programmer, but it makes libraries much more interesting.

Steve Love

Posts: 20
Nickname: essennell
Registered: Sep, 2004

Re: Primitive Types ... In a Library?! Posted: Oct 27, 2004 12:48 PM
Reply to this message Reply
> possible to do things like create interface
> variables to the primitives, delegate interface
> implementations to the primitives, or inherit from the
> primitives. This might not directly be interesting to you
> as a programmer, but it makes libraries much more
> interesting.

Can you expand on that? Interesting how? I'm not being confrontational - honest! - maybe I've missed something.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Primitive Types ... In a Library?! Posted: Oct 27, 2004 12:50 PM
Reply to this message Reply
"It's nothing to be excited about. If you dare to look outside C++/Java/C#, ... "

I am very aware of languages outside of the C++/Pascal realm. My point is that it is exciting for programmers C++ and Pascal derived languages: such as C++/Java/C#/Delphi/Eiffel/D etc. These programmers make up the majority of professional software developers

"... ItThe C struct is not copyable in a meaningful way, it must have a constant address (this is easy to ensure if you malloc a storage for the struct and pass the pointer - you only need to know when to free it). How to wrap such type in Heron?"

Any kind of external type representation can be implemented through external module functions. I would represent the type as a handle, and place it in a class. This requires that the interfaced library provide allocation, deallocation and field access api functions.

The other option is to use _array, which is a pointer to a dynamically allocated array of bytes. This feature may be discontinued at some point though.

Flat View: This topic has 5 replies on 1 page
Topic: Why I Decided to Design a Programming Language Previous Topic   Next Topic Topic: Is the Java Revolution Over?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us