I am creating a new programming language. Much of it is running, but I
need a good mechanism for polymorphism. I currently have good stuff for
things like information hiding, access control, generics, etc., but I need
a mechanism for polymorphism. I wanted something more explicit than what
is done with C++ and Java classes, but I eventually concluded that making
too much be explicit opens more type-safety holes than I can close. My
requirements include:

R1. absolute type safety. This is crucial to my system. There are other
ways within the language to do low-level things.

R2. multi-way polymorphism. C++ does this with multiple inheritance. Java
does it with interfaces.

R3. as explicit as possible in syntax and semantics. In my early attempts,
virtual function tables were explicitly constructed by the programmer,
for example, but I no longer think that is workable.

R4. no implicit run-time type checks. I have explicit checks.

R5. no significant run-time expense. This means no looking up of function
pointers in hash tables - things need to be O(1) execution time.

R6. syntax and semantics as clear and straightforward as possible


My current thinking is to essentially implement Java's class and interface
system, with a few syntactic changes. So, I ask the Java experts among you
some questions:

Q1. Is the Java class/interface system absolutely type safe? I believe the
general belief is that it is. However, if there are little-known
issues, I would like to know about them. It is possible that I can
resolve them in my system. Feel free to privately email me at
cg@graysage.com

Q2. Are there known problems with the Java class/interface system? What
are they? Are there proposed fixes to those problems? Where do I find
those? Please be specific - since this is only one aspect of the
whole that I am building, I can't spend months reading thousands and
thousands of lines of discussions in order to become expert on issues
that aren't directly relevant.

Q3. Are there tricky things that are non-obvious in terms of implementing
this stuff? Short example code that exposes the issues would be good -
I can then use them as test cases.

Note that I am not a Java (or C++ for that matter) expert. I have a lot
of experience with programming languages and compilers, however. You may
need to explain specific terminology, but I should catch on. I am basically
a programmer, not a language lawyer. I have designed and implemented over a
half-dozen programming languages, but I am not active in following any
specific language discussions or processes. I intend the results of my
work, whenever finally ready, to be freely available.

--
Experience should guide us, not rule us.

Chris Gray cg@GraySage.COM
http://www.GraySage.COM/cg/

Rule #1

If security is any issue at all the language must be simple.

The sole reason Java was created was to produce a secure and safe language
for online use.

Largely because of attempts to make the language tick every box on the
"fashiobnable function" sheet Java has turned out to be no more safe or secure
than any other language. Frankly making its very existence pointless.

I don't mean this in any way to denigrate your skills but it seems that if a
team of well paid workers with the resources they had available can't produce
anything vaguely secure - following their lead may not be the best idea.
(Its just an opinion)

Before implementing polymorphism or "classes" or any other popular features I'd
be very wary of the pitfalls.

Most people consider OOP to be the way to develop software - in the real world
the practice is more often in not to just "get the job done" and that often
means resorting to good old fashioned procedural methods hidden away under a
mask of modernistic gloss to please the bosses and marketing people.

Ask yourself exactly what it is you achieve with polymorphism in the real world.
A better more efficient program ? Doubtful. Ease of programming. Nope. Efficient
use of memory and processor time? Absolutely the reverse.

Todays complex methodologies relying on the hidden assumption that computers are
fast and getting faster in order to disguise all manner of inneficient academic
behaviour is all wrong (IMHO of course)

nadia <nospam@example.com> writes:

> If security is any issue at all the language must be simple.

Simple in the stuff that could enable security holes. But, adding stuff that
cannot affect that should not be an issue. For example, I've added some stuff
that I hope is a considerable improvement on C's bitfields, and I hope to
define it in such a way that it can actually be used portably. This adds to
the complexity of the language, but should not be a security hole.

I don't expect the *language* to block denial of service attacks on a system,
for example - I simply wish the language to prevent type insecurity issues.
An example of interest (although I know almost no details) is the old
Burroughs systems, in which most of the OS was programmed in an Algol
variant, and so was less vulnerable to type-security issues.

> The sole reason Java was created was to produce a secure and safe language
> for online use.

That was completely broken by allowing native code, of course. But, does the
rest of the language meet that goal? (Of course, this is not strictly
on-topic for what I'm trying to do.)

> I don't mean this in any way to denigrate your skills but it seems that if a
> team of well paid workers with the resources they had available can't produce
> anything vaguely secure - following their lead may not be the best idea.
> (Its just an opinion)

Can you provide explicit examples where Java *the language* is not secure?
I have no intention of copying Java libraries - my somewhat limited exposure
to them leads me to believe that they are most of the problem with Java's
bloat, for example.

> Before implementing polymorphism or "classes" or any other popular features I'd
> be very wary of the pitfalls.

> Most people consider OOP to be the way to develop software - in the real world
> the practice is more often in not to just "get the job done" and that often
> means resorting to good old fashioned procedural methods hidden away under a
> mask of modernistic gloss to please the bosses and marketing people.

To be honest, I'm really not a fan of OOP. But, I have limited experience
in it. What I want is the polymorphism, not the OO aspects.

> Ask yourself exactly what it is you achieve with polymorphism in the real world.
> A better more efficient program ? Doubtful. Ease of programming. Nope. Efficient
> use of memory and processor time? Absolutely the reverse.

What I'm after is type safety. As my other requirements stated, I want to get
it without any significant cost. My system itself had already grown 4 uses of
internal polymorphism. The two main ones needed in the language system would
require far too much background to explain, but a simple one in a library is
used for the usual "magic cookie" technique. In C, these are often "void *"
values. In Java I imagine they are Object. In both cases, the client code
must cast to their particular cookie type. Using polymorphism, this can be
done with no casts, and still be type safe.

> Todays complex methodologies relying on the hidden assumption that computers are
> fast and getting faster in order to disguise all manner of inneficient academic
> behaviour is all wrong (IMHO of course)

I don't disagree with what you are saying. My early experience goes all the
way back to CP/M systems where you could expect 32K of RAM for the entire
system, and were lucky if you had 56K. My first home compiler was the Draco
compiler (there is a wikipedia entry, but I've never editted it), which was
a one-pass compiler (from source to object file) for those systems. It even
managed to have some simple optimizations in it. It was written in itself.

Thanks for your response.

--
Experience should guide us, not rule us.

Chris Gray cg@GraySage.COM
http://www.GraySage.COM/cg/ (Other)