On 9 May 2001 14:10:20 GMT, kers@hplb.hpl.hp.com () wrote:
>In article <9dbgjf$24m$1@soapbox.cs.bham.ac.uk>,
> jonathan.cunningham@tesco.net writes:
>
>> I suppose it is too late to swap the roles of single and double
>> quotes in the pop11 language, but if we were designing it now, I
>> suspect we would use double quotes as string quotes.
>
>In my descended-from-Pop language Pepper I did indeed eventually
>swop the quotes round. (An interesting rebootstrapping problem it was,
>too.)
I won't address all the points you raise (lack of time) but I'll reply
to some of them.
>> How about this, as a new lexical syntax proposal (somewhat tongue-in
>> cheek, since no one will take it seriously):
(snip)
>> "this is a string"
>> 'word
>> 'c' ;;; a character
>Is ['c'd] a List(Char, Char) or a List(Word,Word)?
An interesting question. You are right that it is necessary to think
about the effect of such a change on all parts of the language.
If, as I'd assumed, the change only applied to tokenisation (as
done by -incharitem-) then ['c'd] would be lexically parsed into
four tokens, bra, char, word, ket, i.e. the above would be the
same as in the existing pop11: [`c`d], which is the same as
putting, "[", `c`, "d", "]" on the front of proglist (uing
existing syntax).
So the answer to your question would be: neither, it's
List(Char, Word).
Or, since there isn't a Char type in pop11, it would actually
be the same as [99 d]. (Since 99 is the ascii code for lowercase c.)
This might not be what we would want.
The effect of ['c 'd] would be similar to what happens now if we
have unwanted double quotes, e.g. what does
["c"d]=>
print? It's actually a list of length four. Similarly ['c 'd] would
(with no other changes) be a list of length four, because "[" and "]"
implicitly quote tokens which are words, but not other tokens.
With a single character mark for quoting words, it might make sense
to *not* have lists quoted in this way, i.e. we no longer need
decorated brackets "[%" and "%]" for unquoting.
But all the commas that are necessary are ugly. Is there a middle
ground?
if line matches [== i think i ??text you] then
[perhaps you think we ^^text each other?]=>
is nicer than
[% "perhaps", "you", "think", "we", text.dl, "each", "other" %]=>
but
['perhaps 'you 'think 'we text.dl 'each 'other '?]=>
is almost bearable. All that makes it different from a [% ... %] list
is that I'm assuming commas are not necssary. After all, in a
stack-based language, why ever have missing separator errors?
How would the semantics of pop11 be changed if, whenever there would
have been a missing separator error, we assume a comma? We do not
need to do away with commas, they may be useful to disambiguate some
situations, but why *require* separators? Are they useful for
anything?
>Actually I lied about the back-quotes. Pepper back-quotes enclose *any
>number* of words, eg 'two words' or 'three little boys'.
Seems a reasonable extension. Is it useful?
>Actually that was still a lie. PBQs quote [] lists and {} vectors too
>(which are not self-quoting in Pepper).
If they are not self-quoting, what does it mean if they are
not quoted? Do you mean the default is like [% ... %]?
(snip)
>> 'this\ is\ two\ words'.
>
>`\"this is two words" .` ;;; I think that's what you meant.
Yes, that's what I meant.
(snip)
>In Spice (a language Steve and I have co-developed and Whose Status Is
>Under Review), character quotes may quote *arbitrarily many* characters,
>and evaluate to all of those characters in sequence, ie
>
> 'burble'
>is
> 'b', 'u', 'r', 'b', 'l', 'e'
If you have separate character quotes, it is more usual (isn't it?) to
treat a multi-character sequence as packing the characters into a
single variable, e.g. in existing pop11 (not Spice or Pepper) I would
expect,
'foo'
to be a 3 character string, I would expect
`foo`
if it made sense, to be the same as
16:666F6F
or maybe
16:6F6F66
(for anyone who hasn't guessed, the characters `f` and `o` are
represented by their ascii codes of 102 and 111, which in hexadecimal
are 66 and 6F.)
So, although this is not (yet?) allowed in pop11,
`foo`=>
ought to print
** 6713199
or to print
** 7303014
[Digression: why doesn't pop11 allow lower case letters in hexadecimal
constants?]
If we want all the characters of 'teardrop' on the stack, we can do
'teardrop'.explode
or
explode('teardrop')
and if you don't like "explode" and want something short, define "^^"
as an explode operator:
^^'teardrop'
then (excuse the rapid switching between pop11 and neopop syntax),
['perhaps 'you 'think 'we ^^text 'each 'other]=>
would also work.
(snip)
>it's pragmatically useful. The current Pepper implementation is such that
>a Word looks just like a String to all String operations; I mean, it
>*really* looks like a String, not that there's code which says, oh, it's
>a word, get the string part. The next-in-dictionary link comes *before*
>the key-and-length, not after).
This is sensible. I wonder how much code would break in poplog if this
change were made? Presumably only fast access procedures of the wrong
type? (I.e. if you used fast_subscrv to access a string, it would
break, but fast string or word accessing system procedures would be
updated along with the change in internal representation, and would
not break.)
Making such a change in poplog cannot be impossibly difficult. John
Gibson made bigger representational changes at various stages in the
evolution of poplog, for example when he implemented sections. But
how much (if any?) existing code would actually break?
And are there any disadvantages?
Jonathan
--
(Trying a new news server) Jonathan L Cunningham
|