🚀 go-pugleaf

In article <26931@megaron.cs.arizona.edu>, gudeman@cs.arizona.edu (David Gudeman) writes:
> In article  <1087@skye.cs.ed.ac.uk> nick@cs.edinburgh.ac.uk (Nick Rothwell) writes:
> I suspect that you have a mental linkage between the term
> "higher-level" and the term "applicative".  You aren't alone in this,
> but I think there are two distinct concepts there, and they should be
> kept seperate.

You're probably right; that's because the properties I associate with
higher level languages (less restrictions on built-in datatypes, first-class
status of data objects, extensible types, heap security, abstraction,
interfaces, modularisation and so on) are mostly seen in applicative
languages. I'm sure that a non-applicative language could support these
properties as well, but I'm not aware of one (although Eiffel comes close,
I suppose, and Modula-3, although it's fairly conventional).

> since if you don't have automatic storage managment, then you are
> extremely limited in the types of first-class objects you can have.
> In fact, I am tempted to define "higher-level" in terms of the
> built-in data types the language suports.

... and how it allows them to be used (as arguments, results, via
polymorphism, in abstractions, and so on). I'd also judge the level of the
language by the sophistication, flexibility, and *soundness* of the type
system (which excludes a lot of languages).

Note that I've refrained from mentioning "pointers"... :-)

> 					David Gudeman

-- 
Nick Rothwell,	Laboratory for Foundations of Computer Science, Edinburgh.
		nick@lfcs.ed.ac.uk    <Atlantic Ocean>!mcsun!ukc!lfcs!nick
~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~
 "Now remember - and this is most important - you must think in Russian."