Re: The Red Language

[bobduff@world.std.com (Robert A Duff)]

In article <340E2DC5.25D7@worldnet.att.net>,
Michael & Amy Hartsough  <Hartsough@worldnet.att.net> wrote:
>What about the "Red" language?

It's interesting, for historical reasons if nothing else.

>I recall reading somewhere (was it an Ada Letters article
>by JP Barnes? Or was it in the "History" chapter of Booch's
>Brown book?) something along the lines of, "The Red language
>contained the seed of a potentially superior language, but
>was deemed beyond the capabilities of then current compiler
>technology."

I think that's bogus.  Red had some nasty holes which made it impossible
to implement, but then so did Green (and so did Ada 83, and so does Ada
95).  If you read the manual assuming anything unimplementable is just
ridiculous, so they couldn't have meant that, and assuming that Red had
undergone all the language bug-fixing that Green did, I think you will
find that Red is no harder to implement than Green.

>Of course, since I'm going by rather old memory, the quote may
>have mentioned either the Blue or the Yellow language, but my
>memory does say, "Red".

I know nothing of Blue or Yellow.  I've read the Red and Green manuals,
as well as various follow-ons of Green, including of course Ada 83 and
Ada 95.

>So. Would the Red language be "doable" with today's compiler
>technology?

Yes, given certain bug fixes.

>... Would it (might it) be superior to present-day
>languages?

In some ways, perhaps, but not overall, IMHO.  Ada has gone a long ways
since those days.  So have lots of other languages.

>Or do we already HAVE the Red language in our midst?
>(Red = Intermetrics = STT = Ada95)  ;^)

The Ada 9X team did not pay a whole lot of attention to Red.  I had read
the Red manual.  Probably Tucker had, too, but Tucker started working at
Intermetrics after Green was chosen to be Ada.  Lots and lots of
languages had some influence on Ada 95.

>From where can I obtain a draft of the Red language?

Beats me.  Maybe Ben Brosgol knows.  I have a paper copy...

In most ways, Red and Ada are similar, which is not surprising, since
they both came out of the same Steelman requirements, and they were both
(very roughly) based on Pascal.

Interesting things about Red:

Its modules are called "capsules" (not "packages").  Capsules are given
in one piece, not spec-vs-body.  (Note recent
mountains-out-of-mole-hills thread about Eiffel classes vs Ada
packages.)

Capsules can be "invoked" as either "old" or "new".  "Old" is sort of
like an Ada with_clause.  "New" is sort of like an Eiffel class, in that
it creates a new copy of that capsule (but not like an Eiffel class in
many other ways, of course.)

No underscores in numeric literals.  I really like Ada's ability to say
1_000_000, rather than 1000000, and I don't understand why many people
on't use it.  Red doesn't allow it.

Enumeration literals are syntactically distinguished (preceding quote).
Every enum type is essentially a character type.

You can declare variables locally within any sequence of statements
without introducing a declare block.

Forward references are allowed to procedures and capsules and so forth,
but not to variables and constants and so forth.  (Again, check out the
recent arguments re: Eiffel vs Ada.)

Assertions (similar in semantics to GNAT's pragma Assert).

Imports clauses -- you have so say what you import, as well as what you
export.  This applies to nested things like procedures, unlike Ada.

Parameter passing semantics is nailed down.  (E.g. the programmer
chooses whether pass-by-ref-read-only vs. pass-by-copy-read-only is
used.)

Strings always start at 1.

You can redefine "=" and "<", and then "/=", ">", "<=", ">=" follow.
Ada does this for "/=", but not the others.  In Red, redefining the
latter four is illegal.

if <statically-false-expression> then
    <something-illegal>
end if;

is a warning, not an error.  Similarly for case statements.  I guess
this is their take on conditional compilation.

Weaker overload resolution rules (than Ada).  Eg no top-down resolution,
except in limited cases.  Function result types not considered for
resolution.  But enum lits can be overloaded (and there's no pretense
that they're functions).

More user-defineable stuff.  Like literal notation, array indexing and
slicing notation, dot-selection notation, etc.  One can redefine the
meaning of case statements and for loops, for a given type.

Case statements are more general than in Ada.  The when's don't need to
be static.  So you can say something like:

    case True is
        when Foo(...) => ...;
        when Bar(...) => ...;
    end case;

where Foo and/or Bar might return True.  If more than one alternative
matches, then the choice is arbitrary!

Function return of caller-unknown-size values is not allowed in Red.

No named-notation parameters.

User-defined finalization.

User-defined assignment.

Generics: Capsules and subprograms can be generic, but so can types.
Generic instantiation is implicit.  (See recent thread arguing about the
readability of such a feature.  The examples in the Red manual look
pretty readable to me, in this regard.)

Tasking uses lower-level primitives (than Ada).  Eg mailboxes.

Delay-until statement.

User-defined scheduling.

Garbage collection seems to be expected.  Unchecked_Deallocation raises
an exception on error, but this can be suppressed.

Uninitialized variables detected at run time.

One suppresses *exceptions* (not checks).  The predefined exceptions are
at a finer granularity than in Ada (which conflates many things under
Constraint_Error, for example).  Green was like Red in this respect
(i.e. Green had one exception for each "check" defined in 11.7, more or
less).

And lots of other stuff.

It's hard for me to judge Red, since I tend to compare it to Ada as it
is today, rather than Green as it was then, which is rather unfair.

Some of it seems better than Ada, some of it seems worse.  I would
particularly miss named-notation parameters, for example.

- Bob