Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bywater!arnor!andreadoria!strom From: strom@arnor.uucp Newsgroups: comp.lang.misc Subject: Re: Need reference for "firewall" modularization Message-ID: <1990Oct31.175117.15517@arnor.uucp> Date: 31 Oct 90 17:51:17 GMT References: <26931@megaron.cs.arizona.edu> <1132@skye.cs.ed.ac.uk> Sender: news@arnor.uucp (NNTP News Poster) Reply-To: strom@andreadoria.watson.ibm.com (Rob Strom) Organization: IBM T.J. Watson Research Center Lines: 92 In article <1132@skye.cs.ed.ac.uk>, nick@cs.edinburgh.ac.uk (Nick Rothwell) writes: |> 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. |> I agree with David. Applicative languages are assignment-free languages based on function application. High-level languages are languages in which machine representations are hidden from the programmer --- the compiler is free to choose data representations and to apply ``aggressive optimizations''. Low-level languages retain ``performance transparency'' --- the property that the reader of the source program can determine what the implementation will be doing at least to the degree that performance can be estimated. Applicative languages and imperative languages can be either high or low level. |> 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). |> Hermes meets all the requirements that you list. (1) All datatypes, including builtin datatypes, are machine-independent. Word size, structure layout, bit/byte order, etc. do not show through. The implementation is free to use clever representations (e.g. storing only a single copy of a large structure). I am assuming that this is what you meant by "less restrictions on builtin datatypes". (2) All types are first-class. That is, they can be put in tables, sent in messages, passed as parameters, etc. (3) There is a type-definition mechanism and a powerful set of type constructors for tuples, tables, call-messages, etc. (4) Storage leaks are avoided through typestate checking (see my earlier posting in this thread). This guarantees that all objects are finalized on termination of a process. (5) Super-lightweight processes provide "abstraction, interfaces, modularisation and so on". Hermes is strictly imperative. Each process has variables and assignments. These variables are not visible to other processes, however. Wirth, who developed Pascal and was a designer and advisor for the Modula-n efforts, supported performance transparency and opposed complex compilers. Our research group is exploring the opposite philosophy. We believe that hiding low-level details makes programming easier, and programs more portable. We conjecture that starting from a more abstract model facilitates optimizations that will generate efficient implementations on diverse target platforms. We're willing to give up performance transparency (most of the time) in exchange for performance. We are currently exploring some ``aggressive optimizations'' for distributed and multithreaded environments. An example is transparent process replication to increase concurrency and reduce communications costs of a process which at the source level looks like a performance bottleneck. Other imperative languages (e.g. SETL, CLU, APL) are high-level. I therefore disagree that high-level in practice implies applicative. |> > 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). |> I understand *soundness* for inferencing/checking techniques but can you elaborate on what it means for the type system itself to be sound? |> Note that I've refrained from mentioning "pointers"... :-) |> |> > David Gudeman |> |> -- |> Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. |> nick@lfcs.ed.ac.uk !mcsun!ukc!lfcs!nick -- Rob Strom, strom@ibm.com, (914) 784-7641 IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10958