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"]
>
> I have been reading (skimming) the recent discussion with interest,
> knowing well that anything written by Jonathan or Chris is likely to be
> interesting and useful.
Thank you, kind sir.
> However I have a few meta-comments on the discussion.
>
> (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.
[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.]
> (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
|