[gpzF93@hamp.hampshire.edu: Re: HLL and misa...]

[Rainer Blome]

hi fare,

man, was i confused when i realized that some of thaose messages didn't
come from tunes@ens.  i don't even remember where my replies to those
messages that had tunes missing as from- or cc- field went (i had just
added tunes as a cc entry).

here's what you asked for:

Return-Path: <gpzF93@hamp.hampshire.edu>
To: rainer@physik3.gwdg.de (Rainer Blome)
Cc: gpzF93@hamp.hampshire.edu
Subject: Re: HLL and misa... 
In-Reply-To: Message from rainer@physik3.gwdg.de (Rainer Blome) 
 of "Thu, 15 Jun 1995 19:10:09 +0200." <9506151710.AA16027@zaphod.physik3.gwdg.de> 
Reply-To: gzenie@hamp.hampshire.edu
Date: Thu, 15 Jun 1995 14:08:37 -0400
From: garth zenie <gpzF93@hamp.hampshire.edu>

On Thu, 15 Jun 1995 19:10:09 +0200  Rainer Blome wrote:

i'm going to start from the bottom... 

> oops - i can see one more thing:
> 
> > `get' would be able to figure out what you were doing by the "types" of
> > objects you supply to it.
> 
> this probably means that you are using the generic function approach.  big
> loose, in my opinion.

no - we're not into generic functions for a number of reasons:

a) fixed number of parameters.
   in the example it is implied variable arguments.  for example, you
   don't know how many indices an array will have.
b) dispatch on type.
   we want to be able to dispatch on anything - not just the type of
   object that it is...
c) won't work in concurrent/distributed environments
   in order to do a dispatch you have to have all of the objects in
   one place, locked.  this is no good.

we have chosen to adopt a message passing paradigm based roughly on
smalltalk.  this is the only way to be able to be concurrent.  method
dispatch can be simlauted on some level through message passing.

the whole language is based on four messages: get, put, async-get,
async-put.  we are working on a nice clean metaphor for the async
v. sync messages.  of course the macro system will be used so once you
get to a higher level of the language you not oing to have to say (get
...) for every message.

> a taste of air, you mean?.  for the technical level sometimes reached on
> this list, you may well be a lot more concrete.

as i have a job working 60hrs/wk until mid-july i am inclined not to
go into amazing detail as i have to be very conservative with the
small amount of free time i have.  i am sorry.

> could you use more descriptive words?  powerful says nothing, consistent is
> implied by simple and simple is implied by concise.  so all i can make out
> so far is that you are building a concise concurrent lisp with some
> smalltalk features

powerful: all the functionality of CLOS plus more 
	a) a rich class hierarchy
	b) concurrent from the ground up
	c) completely modifiable (dynamically)

concise: all functionaity to be described in 50 pages or less

modifiable: 
	a) all source code provided
		i) language is written in itself minus a tiny core of
		   functions required to bootstrap the compiler object
	b) everything is an object including:
		i) compiler
		ii) code	
		iii) parser
		iv) object definition
		v) language definition
		vi) "function" definition

abstract:
	a) not defined in terms of hardware
	b) human interface

it will of course by a hybrid object-oriented functional language.

i will write more tonight. please send me any comments you have on the
above.  

-- garth