The Red Language 
Author Message
 The Red Language

On Thu, 04 Sep 1997 11:38:00 -0400, "Dean F. Sutherland"

Quote:

>We used a descendent of Red as our main implementation language at
>Tartan in the mid-80s. ... Gnal ... Tartan was named in honor of
>the company's roots at Carnegie-Mellon.

I stand corrected.  I was thinking of a language design called
"Tartan" that was done in answer to the four colored design
proposals.  The name that comes to mind is Mary Shaw (and wasn't
she at CMU then?) but I'm not sure about that.  (I do remember
where the report was on the shelves of the SofTech library some
two decades ago.)

Tartan was done as a protest of the complexity of the four
bespoke designs.  It was much simpler; the specification was
about 1/20th as thick as the others (I know, that's not a very
good measure of language complexity).  It was said to be compliant
with Steelman, a claim I was unqualified to evaluate.  (I do
remember John Goodenough saying that our (SofTech's) design
(Blue?) came closer to meeting that goal than did Green or either
of the others, and that we should have been a bit less fanatical
about Steelman.  Hey, how does Ada95 do against Steelman?  It
might be interesting to hear in what major ways Ada95 violates
the old requirements.)

Bob Munck
Mill Creek Systems LC



Mon, 21 Feb 2000 03:00:00 GMT  
 The Red Language

Quote:
> How does this differ from a function with a pragma Inline, and a
> compiler that does inlining?

The first significant difference that I recall is that Gnal required
that the inlining must occur, even across compilation units.  As you
know, Ada's pragma Inline is advisory; compilers may ignore it if they
so choose.

The second difference is the name binding.  Arguments were evaluated on
each reference in the routine, rather than just once at the call site.
Note that name binding was a choice you could make, it was not required.
(Looking at my old Gnal manual, I find:

nam     This primary binding mode is permitted only for formals of
        inline functions and abbreviations.  Each reference to the      formal
results in a reevaluation of the actual object
        expression.

Extracted from section 6.3, binding rules)
Other choices for binding were val, ref, any, and repval.

Dean



Tue, 22 Feb 2000 03:00:00 GMT  
 The Red Language

Michael said

<<So. Would the Red language be "doable" with today's compiler
technology? Would it (might it) be superior to present-day
languages?

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

No, Ada 95 is nothing like Red (at least not in the respects where
Red and Green most importantly differed). The genesis of Ada 95,
despite your rather confused equation, is that first a requirements
document was written, which was very much foucssed on the revision
requests that had been received. As one of the authors of this document,
I cannot remember Red coming up at any point during writing the requirements.

Then, given these requirements, a contract was let to Intermetrics to design
to these requirements, and at that point the design effort, lead by STT, but
involving many others of course, was a process of realizing these requirements,
which of course were only guideposts, nothing like a full language design.

But even in this later design process, I can barely remember Red being
considered as a source of inspiration. Most of the critical missing
capability in Ada 83 was also missing in GNAT, so mostly Red/Green
differences were simply not relevant to the process.

Do not assume that everyone agrees with the idea that Red was superior,
but too hard to implement. I personally *always* preferred Green from
a technical point of view, even allowing for the fact that Green was
far more polished and complete than Red.



Thu, 24 Feb 2000 03:00:00 GMT  
 The Red Language

Bob says

<<Tartan was done as a protest of the complexity of the four
bespoke designs.  It was much simpler; the specification was
about 1/20th as thick as the others (I know, that's not a very
good measure of language complexity).  It was said to be compliant
with Steelman, a claim I was unqualified to evaluate.  (I do
remember John Goodenough saying that our (SofTech's) design
(Blue?) came closer to meeting that goal than did Green or either
of the others, and that we should have been a bit less fanatical
about Steelman.  Hey, how does Ada95 do against Steelman?  It
might be interesting to hear in what major ways Ada95 violates
the old requirements.)>>

One obvious violation is the presence of pointers to procedures, which
were specifically ruled out (for good reason) by Steelman! There are
undoubtedly others, but this comes immediately to mind :-)



Thu, 24 Feb 2000 03:00:00 GMT  
 The Red Language

Quote:

><<Hey, how does Ada95 do against Steelman?  It
>might be interesting to hear in what major ways Ada95 violates
>the old requirements.)>>

>One obvious violation is the presence of pointers to procedures, which
>were specifically ruled out (for good reason) by Steelman! There are
>undoubtedly others, but this comes immediately to mind :-)

There was an article "rating" Ada95, C, C++, and Java against Steelman
in the latest Ada Letters (XII.4).

That was one.  Another is 3-3F (nonassignable record components).   The
third was 10F (assertions, but they point out that GNAT has this).
There was also 5 "partial" and 11 "mostly" entries.



Fri, 25 Feb 2000 03:00:00 GMT  
 The Red Language

: Michael said

: <<So. Would the Red language be "doable" with today's compiler
: technology? Would it (might it) be superior to present-day
: languages?

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

: No, Ada 95 is nothing like Red (at least not in the respects where
: Red and Green most importantly differed).

Although I work at Intermetrics, I have very little familiarity
with "Red."  I joined Intermetrics in September 1980, after the "Red"
language effort was over, and John Nestor had left for "greener"
pastures ;-).

Almost all of the ideas for Ada 95 were based on experiences with
Ada 83 and other 80's languages such as C++, Modula-X, CLOS, etc.
plus reading knowledge of other languages such as Oberon, ORCA,
Haskell, etc.

--

Intermetrics, Inc.  Burlington, MA  USA



Fri, 25 Feb 2000 03:00:00 GMT  
 The Red Language



Quote:
>The first significant difference that I recall is that Gnal required
>that the inlining must occur, even across compilation units.  As you
>know, Ada's pragma Inline is advisory; compilers may ignore it if they
>so choose.

How can a language definition *require* any such thing?  How could you
test whether the implementation did so?

- Bob



Fri, 25 Feb 2000 03:00:00 GMT  
 The Red Language


Quote:



> >The first significant difference that I recall is that Gnal required
> >that the inlining must occur, even across compilation units.  As you
> >know, Ada's pragma Inline is advisory; compilers may ignore it if they
> >so choose.

> How can a language definition *require* any such thing?  How could you
> test whether the implementation did so?

Well, the language definition required it saying in the document that
that was how the language worked.

Since the main target of the language definition (written by John
Nestor) was the implementation team (John Nestor), testing of this kind
never showed up as an issue.  John said he would do it; later he said he
had done it.  We believed him; why not?

Bob: I think maybe you've been involved too long with Ada.  :-)

Art

Arthur Evans Jr, PhD
Ada Consulting



Sat, 26 Feb 2000 03:00:00 GMT  
 The Red Language

Art said

<<Well, the language definition required it saying in the document that
  that was how the language worked.

  Since the main target of the language definition (written by John
  Nestor) was the implementation team (John Nestor), testing of this kind
  never showed up as an issue.  John said he would do it; later he said he
  had done it.  We believed him; why not?

  Bob: I think maybe you've been involved too long with Ada.  :-)>>

Just because a language definition says XXX does not make it so,
if the statement is vacuous.

For example, supposed we come across a statement in a language definition
that sayys

  All procedures in this language shall be octagonal.

Now we go and look up in the index what octagonal means, and if we don't
find a definition, then at best this is a comment with no normative force,
and at worst it is rubbish.

A statement that certain procedure calls shall be inlined is similarly
dubious in the absence of a definition of inlining *at an appropriate
level of abstraction* -- a definition that talks about generated code
is junk, since you cannot define the notion of generated code in abstract.

Remember that a compiler is always allowed to treat a language definition
"as-if", which means that any generated code that makes a compiler run
the code the same way as some other way is equivalent. Since inlining
has, by definition, no semantic effect, it is obvious that semantic
rules in the language can neither require it nor proscribe it.

As for "we believed him, why not?", the why not is because the claim was
on its face unsupportable!



Mon, 28 Feb 2000 03:00:00 GMT  
 The Red Language

I guess that Robert is correct for the general case of specifying inline
expansion.  There's one specific case where I believe that the Gnal
"spec" does indeed reasonbly "mandate" inline expansion (possibly even
to Robert's satisfaction).

Routines with nam binding for their formals would seem to "require"
actual inline expansion.  (You'll recall from earlier in this thread
that nam binding specifies re-evaluation of the actual object expression
from the call site at each reference in the body of the routine.)
Treating this as (fully semantically checked) macro expansion is the
obvious and straightforward way to achieve this effect.

On the other hand, I suppose that one _could_ do something with
carefully produced function closures or some other such hack (I mean
workaround) -- but I'm hard pressed to see why it would be worth the
effort.

A formalist might argue that, given the lack of a formal language
definition, the inline expansion "mandate" is no more than strongly
worded implementation advice.  Of course, this would also imply that
many common procurement specifications for compilation systems are also
no more than strongly worded implementation advice...

Dean



Mon, 28 Feb 2000 03:00:00 GMT  
 The Red Language

Quote:

> Just because a language definition says XXX does not make it so,
> if the statement is vacuous.

Robert: You are missing the point entirely.  If a language definition,
like Ada, is to be useful in the presence of implementors other than the
designer, then of course it's vacuous to imclude specifications that
cannot be tested.

OTOH, if the only implementor is the designer, and the definition is
provided largely for the language's users, then such specs are of
interest to the users, and therefor useful.  That was the situation in
gnal.

Quote:
> Remember that a compiler is always allowed to treat a language definition
> "as-if", which means that any generated code that makes a compiler run
> the code the same way as some other way is equivalent. Since inlining
> has, by definition, no semantic effect, it is obvious that semantic
> rules in the language can neither require it nor proscribe it.

If inlined code is more time-efficient and the app thereby makes its
deadlines but does not otherwise, then there's a semantic effect.  The
plane flies one way; it crashes the other.

Quote:
> As for "we believed him, why not?", the why not is because the claim was
> on its face unsupportable!

There are places in this world where folks say things and other folks
believe them.  The GNAT documentation explains the circumstances in
which 'pragma inline' has an effect; I believe what is written.  In
fact, I could test the claim by examining compiled code; why bother?

Art



Mon, 28 Feb 2000 03:00:00 GMT  
 The Red Language


: ><<Hey, how does Ada95 do against Steelman?  It
: >might be interesting to hear in what major ways Ada95 violates
: >the old requirements.)>>
: >
: >One obvious violation is the presence of pointers to procedures, which
: >were specifically ruled out (for good reason) by Steelman! There are
: >undoubtedly others, but this comes immediately to mind :-)

: There was an article "rating" Ada95, C, C++, and Java against Steelman
: in the latest Ada Letters (XII.4).

This paper is also available on-line.
It's called "Ada, C, C++, and Java vs. The Steelman" and it's at:

  http://www.adahome.com/History/Steelman/steeltab.htm

This paper gives the exact Steelman text and how well each of these
languages supports the Steelman requirement (with additional commentary).

I would not use the term "rating"; the paper is simply a comparison.
Here's the abstract of the paper:
"This paper compares four computer programming languages (Ada95, C, C++,
 and Java) with the requirements of "Steelman", the original 1978
 requirements document for the Ada computer programming language. This
 paper provides a view of the capabilities of each of these languages,
 and should help those trying to understand their technical
 similarities, differences, and capabilities."

And note the concluding paragraph:
"Again, users of this paper should apply caution; differing percentages
 of "yes" values and capabilities do not necessarily imply that a
 particular language is more suitable than another for a given specific
 task. Readers should examine each answer and determine which "yes" and
 "no" values are of importance to them. This information is intended to
 help readers gain additional understanding of each of these different
 languages."

Also - an electronic version of Steelman is available at:
  http://www.adahome.com/History/Steelman/intro.htm

--- David A. Wheeler



Tue, 29 Feb 2000 03:00:00 GMT  
 The Red Language



Quote:
>What about the "Red" language?

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

Quote:
>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 {*filter*} 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.

Quote:
>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.

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

Yes, given certain bug fixes.

Quote:
>... 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.

Quote:
>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.

Quote:
>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



Tue, 29 Feb 2000 03:00:00 GMT  
 The Red Language



Quote:
>I guess that Robert is correct for the general case of specifying inline
>expansion.  There's one specific case where I believe that the Gnal
>"spec" does indeed reasonbly "mandate" inline expansion (possibly even
>to Robert's satisfaction).

I doubt it.  (That is, I doubt it's to Robert's satisfaction.  It
certainly doesn't satisfy me.)

Quote:
>Routines with nam binding for their formals would seem to "require"
>actual inline expansion.  (You'll recall from earlier in this thread
>that nam binding specifies re-evaluation of the actual object expression
>from the call site at each reference in the body of the routine.)
>Treating this as (fully semantically checked) macro expansion is the
>obvious and straightforward way to achieve this effect.

I assume that "nam" binding is the normal Algol notion of by-name
parameter passing.  I believe that passing thunks (ie function closures)
was the expected way to implement it in Algol.

Quote:
>On the other hand, I suppose that one _could_ do something with
>carefully produced function closures or some other such hack (I mean
>workaround) -- but I'm hard pressed to see why it would be worth the
>effort.

I'm not convinced it's easier to implement using macro-expansion.  And
thunks might in fact be more efficient in some cases.  Anyway, I'm not
sure why you consider it a hack/workaround, since it was, apparently, a
well-known implementation technique in the 1960's (before I knew what a
computer even was).

Quote:
>A formalist might argue that, given the lack of a formal language
>definition, the inline expansion "mandate" is no more than strongly
>worded implementation advice.

I do so argue.

Quote:
>...Of course, this would also imply that
>many common procurement specifications for compilation systems are also
>no more than strongly worded implementation advice...

Indeed.

- Bob



Tue, 29 Feb 2000 03:00:00 GMT  
 The Red Language

Quote:

>: There was an article "rating" Ada95, C, C++, and Java against Steelman
>: in the latest Ada Letters (XII.4).

>This paper is also available on-line.
>It's called "Ada, C, C++, and Java vs. The Steelman" and it's at:

>  http://www.adahome.com/History/Steelman/steeltab.htm

>This paper gives the exact Steelman text and how well each of these
>languages supports the Steelman requirement (with additional commentary).

The paper overall was good, but I must say I disagreed with some of the
ratings.  That is, I thought there were several cases where the paper
claimed that Ada met a requirement that it does not.  I also think that
some (small number) of the Steelman requirements were foolish, and it
was quite right of Jean Ichbiah to violate them (or, in a few cases,
where he should have been more bold, and violated them where he didn't).

- Bob



Tue, 29 Feb 2000 03:00:00 GMT  
 
 [ 58 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. Code Red worm and typed languages

2. visual works 3.1 image has segmentation fault on 2.4 kernel (red hat 8.0)

3. GNU Smalltalk 1.6.1 on Red Hat 5.2

4. Red Herring (was: Bitten by dynamic typing...)

5. red screen of death (pluggableTextMorph bug?)

6. Computer loses RED color

7. red and white WINE STRICTLY KOSHER

8. awk2c on Red Hat 5.0

9. IBMs Red Book?

10. red wine

11. Info Week article: Java's Not So Red-Hot

12. Off topic: Red Icon on drive letter

 

 
Powered by phpBB® Forum Software