[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 14 08:56:01 2001 
Subject:Re: Syntactic vs semantic extensions (reply part "a") 
From:Jonathan L Cunningham 
Volume-ID:1010514.03 

On 11 May 2001 12:14:35 GMT, kers@hplb.hpl.hp.com () wrote:

>In article <9dghbi$csm$1@soapbox.cs.bham.ac.uk>,
>	Aaron.Sloman.XX@cs.bham.ac.uk (Aaron Sloman See text for reply address) writes:
>> [To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
(snip)
>> (a) If the suggestions currently being discussed were implemented, so
>> much would break both in the system and in user libraries that I think
>> it is better to think of them as proposals for a new language (spice?),
>> not proposals for changes to Pop-11, 
>
>I agree. I was commenting on Jonathan's comments from the standpoint of
>someone who's had a go at building new languages which inherit (I hope)
>the good parts of the style of Pop11, rather than suggesting that any
>particular change be implemented.

I also agree. The problem is that (here is aa Universal Truth) what
can no longer change has started dying.

But, using a biological metaphor, programming languages are more like
bacteria than higher organisms. A language improvement in one language
can be taken up by other languages, and ...

>[Although I *would* suggest that we seriously consider changing the string
>quotes to " and the character quotes to ' and the word quotes to something
>else again, eg `, while preserving the existing code-base. While I dislike
>arguments in the style of "but languages X, Y, and Z do it the other way",
>Pop's use of quotes does seem to be unusual.]

 ... if we wanted to do this, the way forward would be a new dialect
of pop. (There were already proposals for this back in
the '90s.)

I'm not suggesting anyone has the time or energy to do this, but if
they did, I think the way forward is:
(1) Don't break any existing code.
(2) Don't gamble on the adoption of a new language.

By (2), I mean that it is unlikely existing users would want to switch
to Spice, or Pepper, even if available in poplog. (I could be wrong.)

But they have some good ideas, and improvements. To the extent that
these are incompatible with pop11, (1) means they can't be tried
by existing poplog users, but only by installing and trying out
different implementations. Which, with the best will in the world,
is not so easy as trying out new features in a system you already use.

I think the way forward would be to make a new poplog subsystem, which
is called pop2002 or something. This, initially, would use the pop11
compiler. All the pop11 libraries would be available.

This subsystem could then be hacked about with experimental new
features, (such as swapping around the meanings of quotes, making
non-quoted lists the default etc.). In particular, it could
incorporate good ideas from new languages such as Chris and Steve
have been working on, without demanding the effort of implementing
a whole language.

This is not as crazy as it sounds. The languages C++ and C are
different languages (C is not a subset of C++) and have
incompatibilities. Yet most C++ compilers can also compile C,
and there is no problem using both languages in the same program.

Similarly, it would be easy (much easier than mixing pop11 and prolog)
to have slightly different dialects of pop co-existing in poplog.
The compilers would share code. The section mechanism makes this easy.

Actually, I would have another wish for this: any new dialect of pop
should eventuall replace the "system" dialect of pop, which is already
so different from normal pop11 that it is incomprehensible to the
ordinary pop11 programmer. Poplog was originally written in pop11.
Current versions of poplog are not (IMNSHO).

But in the short term, the new dialect of pop would be as different
from system pop as pop11 is.

>> (b) [For information only] Pop-11 already has mechanisms for dealing
>> with two types of representations for characters.
>> 
>>     1. There's the standard ASCII representation as an 8-bit integer
>>     2. There are also "display strings", which are used in Ved/Xved
>
>While I appreciate the intentions of, and the work that's gone into, 
>the dstring type, I'm not convinced that it's the right approach. For
>example, it doesn't generalise to multiple-font lines. However, in the
>absence of any (on my part!) practical experience, I can only report
>misgivings and not attempts-in-progress.
>
>> (c) My own feeling is that although the recent discussions of syntax for
>> various types of data-constructing expressions are interesting and
>> could, if they had occurred around 1970, have led to much better syntax
>> for the pop family,
>
>It's not clear to me that they *could* have occured then; many of the
>opinions I (and Steve) have arise from seeing how the existing Pop11
>expressions worked "in practice" and trying to find clean fixes for
>(what are in our opinion) problems. 
>
>> they are far less important for real users than
>> other "semantic" issues like the availability of powerful libraries that
>> extend what you can easily do, the availability of new debugging and
>> development tools, etc.
>
>I agree, but only partially. It's important that the surface syntax
>be, urm, "cleanly composing", ie that the parts all fit together 
>smoothly, and that mistakes show up as mistakes and not mysterious
>behaviours later. I think that this shows up in other languages
>(I'm thinking particularly of Smalltalk and Java here) where the
>syntax seems to actively conspire against straightforward expression
>of intent.
>
><hobbyhorse>
>My experience with Pepper has convinced me that allowing arbitrary
>procedures to be called both postfix (as in Pop's X.F) and indeed
>infix (as in object-classy X.F(A) and in Pepper's X @F A) is a
>significant syntactic improvement to a language.
></hobbyhorse>
>
>(Extensive list of semantically wonderful stuff deleted)
>
>> By comparison with "semantic" extensions of the above types, I believe
>> changes to the syntax of existing constructs are really of marginal
>> importance!
>
>Not for beginners, or people you're trying to seduce to the Way, or
>when you're trying to eliminate the nasty little code production burrs.
>
>I find, for example, that writing Pop `for` loops is irritating *just
>because* the control identifiers are not declared and scoped by the 
>`for` construct itself. It doesn't matter much what the powerful
>semantic domains at my disposal are: this niggle doesn't go away.
> 
>> (Though interesting as examples of programming language design issues
>> for people designing a language from scratch.)
>
>Actually, I think they're interesting examples of PLD issues for
>languages being designed *not* from scratch, but from a basis of
>existing languages. While Spice, for example, isn't Pop11, it does
>borrow ideas heavily from it, and it wouldn't be the language it is
>without my experience of Pop. In particular, Spice's approach to
>multiple values is a direct result of Steve and I saying "how can we
>get the really neat parts of the Pop open stack without buying into
>bizarre stack-depth errors?". I think we've done a really good job
>there, and in the not-too-distant future I hope to speak rather more
>fully about it.
>
>-- 
>Chris "owes a lot to Poplog" Dollin
>C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html

-- 
Jonathan L Cunningham