[e-lang] Re: Time to think about parallel Smalltalk stuff

David Hopwood david.nospam.hopwood at blueyonder.co.uk
Mon Jan 24 23:27:49 EST 2005


Brian T. Rice wrote:
> Well, I'm interested in concurrency /before/ security, since we currently 
> have NO concurrency, which that email stated.

Concurrency and security are utterly inseparable. This is not obvious;
it's true because any semantics of a language has to first specify which
primitive operations are possible. This determines both its concurrency
model and its most important security properties.

> I was mostly annoyed that there was zero response from my email,

It's very easy for any single mail to get no response if the people who
would have responded are working on something else at the time. It does
not necessarily imply lack of interest. You probably should have been a
bit more persistent (this is not meant as a criticism).

> and that E's implementation is so steeped in 
> Java backwardsness that I spent months just trying to decipher any lessons it 
> had (there's an extended rant based on this with my frustrations with the E 
> language as a whole - I'm subscribed to the mailing list, and 80% of the 
> content is noise and confusion surrounding this horrible inflexible syntax! 
> I'm aghast. After a year toying with E, I still can't read it or program in 
> it.)

<http://c2.com/cgi/wiki?WadlersLaw>

# PhilipWadler's Law of Language Design
#
# In any language design, the total time spent discussing a feature in
# this list is proportional to two raised to the power of its position.
#
#    0. Semantics
#    1. Syntax
#    2. Lexical syntax
#    3. Lexical syntax of comments

More seriously: yes, it's frustrating that syntax gets in the way so much.
OTOH the Lisp approach of having a very simple, uniform syntax that is
not specialized to particular constructs demonstrably doesn't work for
many people.

One way to avoid getting so bogged down in syntax is to make a conscious
effort to talk more about kernel languages, for which syntax is not
so important. The book "Concepts, Techniques and Models of Computer
Programming"
(http://c2.com/cgi/wiki?ConceptsTechniquesAndModelsOfComputerProgramming)
has really impressed me with how simple a kernel language can be while
supporting a highly expressive full language.

I think that it would be very worthwhile to try to determine what kernel
language would be needed to support, say, {E, Slate, Oz, Erlang,
Haskell, O'Caml, Scheme}, subsetted for security where necessary.
(Although the definition of "kernel language" used by CTMCP requires it
to be a syntactic subset of the full language, this is only a convenience,
not a necessity -- it's quite possible to translate several full languages
into the same kernel language.)

If we can develop a unified kernel language for object-functional
capability-secure languages using message passing concurrency, that
would be directly useful for implementation and for language
interoperability. If we can't, then understanding why not would probably
still be enlightening.

> I do apologize again for the exaggerations and manner of introduction. It 
> really did bother me that I didn't get a response after people had been 
> casting about for ideas on how to integrate and even cross-posting 
> announcements on collaboration.

I am in no doubt that people involved with Slate and E care deeply about
improving programming language technology. However, it takes time to grasp
a language in sufficient depth to make useful comments on its design --
time that is in short supply for many of us. Another factor is that it
often seems redundant (although really it is not) to simply say that you
agree with some aspect of a design. So far I've found very little to
disagree with about the semantics of Slate in particular -- although I am
preparing several posts on concurrency and capability secure languages in
general that would be relevant to Slate (watch this space).

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>



More information about the e-lang mailing list