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

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

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

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

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

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 12:19 PM

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.

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 26, 2004 11:33 PM

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 2:13 AM

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 8:44 AM

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 9:48 AM

> 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 9:50 AM

"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

Previous Topic

Next Topic


	Web Artima.com