[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ISO/European



We have a contact that apparently is involved in the ISO standardization work.
Julian Padget is a professor at the University of Bath in England (John Fitch
is another professor with an account that they share - which is why the
strange return address).  Anyway,
the following are parts of some conversations between Julian and us.  Please
don't redistribute it, but it makes for interesting reading.  I think it might
give you some insight into what they are thinking:

	From Fitch%cs.ucl.ac.uk@Cs.Ucl.AC.UK Mon Dec 16 15:24:29 1985
	Received: from Cs (cs.ucl.ac.uk) by utah-orion.ARPA (5.5/4.40.2)
		id AA03657; Mon, 16 Dec 85 15:23:55 MST
	Message-Id: <8512162223.AA03657@utah-orion.ARPA>
	Date:     Mon, 16 Dec 85 22:19:07 GMT
	From: Fitch%cs.ucl.ac.uk@cs.ucl.ac.uk
	To: shebs@utah-orion.arpa, kessler@utah-orion.arpa, galway@utah-orion.arpa
	Subject:  European common LISP
	Status: RO
	
	Thanks for the summary of the Boston meeting.  Any other tidbits will be
	welcome.  It may not come as much of a surprise to hear that John and I
	are the UK representatives on the European standardisation group.  You
	might even perceive my hand in the plan for a smaller and formally defined
	LISP!  The current schedule calls for us to meet on the first moday of
	every month (most likely in Paris at IRCAM (dial 4000 for Boulez)).
	
	The name for the language is EU-LISP, which when franglaised (pardon my
	verbing) is l'EU-LISP whic is not so different from Le-LISP!
	
	Presently our energies are directed toward trying to produce an operational
	semantics for EU-LISP (on the basis that denotational gets too complicated
	with all those stores, environments and continuations and is only meaningful
	to an expert, abstract semantic algebras and initial algebras are too
	darned hairy and group/category theoretic semantics, similarly, require too
	much background to be intelligible to the average implementor).
	
	No doubt you can also work out why Utah is somewhere we can trust - your
	(original) aims (you have recently been a little diverted!) do 
	coincide, in part, with ours.  The sooner Will gets over here the sooner
	he can go spend the weekend in Paris!!
	
	--Julian.
	
	PS: If you have suggestions/questions please fire away.
	
	
	From Fitch%cs.ucl.ac.uk@Cs.Ucl.AC.UK Tue Dec 17 08:02:31 1985
	Received: from Cs (cs.ucl.ac.uk) by utah-orion.ARPA (5.5/4.40.2)
		id AA06602; Tue, 17 Dec 85 08:02:00 MST
	Message-Id: <8512171502.AA06602@utah-orion.ARPA>
	Date:     Tue, 17 Dec 85 14:47:54 GMT
	From: Fitch%cs.ucl.ac.uk@cs.ucl.ac.uk
	To: shebs <@UTAH-CS:shebs@utah-orion.arpa>
	Cc: galway@utah-orion.arpa, kessler@utah-orion.arpa
	Subject:  Re:  European common LISP
	Status: RO
	
	The intention is for something in the *spirit* of SCHEME and 3-LISP but
	without the iconiclasm.  Why do you believe that whatever we have to do is
	going to be a *subset* of Common LISP?  CL was not designed...nor was any
	consideration given to a need to subset - but I need hardly tell you lot 
	that; you have been through the manual and the problems many times.
	
	I am surprised you find denotational semantics straightforward or easy for
	CL.  BTW have you read the paper by Muchnick and Pleban in the 1980 LISP
	conference proceedings - that will show you how messy things can get.  Stores,
	environments and continuations are pleasant enough mathematical concepts (and
	a handy way of circumventing the problem), but trying to synthesize an
	implementation from such a description is not something I'd care to tackle
	before breakfast.
	
	Because I think it is important that many people be able to read the 
	definition once written and, more importantly, thereafter produce a
	working conforming system, operational semantics has greater appeal.
	
	λWe plan (the europeans that is) to implement our design in parallel on
	Leâ??LISP and Cambridge LISP (PSL if I had it!) a little behind the definition
	group.
	
	Would you mind explaining the remark in your summary of the Boston meeting that
	was along the lines of "...if it had been known that the Europeans did not
	approve of certain things in CL, a different decision might have been made".
	Apologies for paraphrasing you!  I have also had a report from Jerome of
	events - he said that Mathis was spouting anti-europeanisms and was
	particularly negative about the French.  Can you tell me what Mathis said 
	please?
	
	I shall be in Tampa for POPL - see you there?
	
	--Julian.
	
	
	From shebs Tue Dec 17 08:56:39 1985
	Received: by utah-orion.ARPA (5.5/4.40.2)
		id AA06835; Tue, 17 Dec 85 08:56:33 MST
	Date: Tue, 17 Dec 85 08:56:33 MST
	From: shebs (Stanley Shebs)
	Message-Id: <8512171556.AA06835@utah-orion.ARPA>
	To: @UTAH-CS:shebs@utah-orion.arpa, Fitch%cs.ucl.ac.uk@cs.ucl.ac.uk
	Subject: Re:  European common LISP
	Cc: galway@utah-orion.arpa, kessler@utah-orion.arpa
	Status: RO
	
	Not to get into big arguments, but the main reason I favor Common
	Lisp is that it is by and large a conservative design.  Recall that
	the purpose of the standard is to facilitate porting programs around
	between different implementations.  If so, then compatibility with
	existing code is far more important than semantic elegance.  There
	is just too much Lisp code out there for anyone to say "you can't
	have a variable 'list' and use the function 'list' in the same scope",
	even if everybody fervently believed that single-cell Lisps were the
	way to go.  If this weren't a problem, Fortran and Cobol would be
	of purely historical interest and everybody would be running Lisp
	or some other wonderful and high-level language.  I would guess that
	there is maybe a million lines of Lisp code that would have to be
	converted, not to mention thousands of programmers.  Common Lisp
	isn't intended to be elegant; it's intended to be compatible.  If
	I write a CL program today, I know it will work on a dozen Lisps,
	but if I write a 3-Lisp program today, it won't run much of anywhere.
	I would save elegant languages for research and for future standards.
	As one of the Gang of 5 commented, "It's hard to test out things in
	your head".  I would add a corollary that "things that are easy to
	specify are not necessarily easy to use"...
	
	Enough of this - I'm planning to get warm in Tampa, so we can continue
	the diatribes (oops, I mean continue the discussion :-)!
	
								stan