[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 11 07:33:15 2001 
Subject:Re: Editing filenames with spaces 
From: 
Volume-ID:1010511.01 

In article <3afab384.9311545@news.cis.dfn.de>,
	Jonathan.Cunningham@tesco.net (Jonathan L Cunningham) writes:
> 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.

OK.

>>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).

Aha. I'd assumed that the 'c' would be recognised by the lexer; now
I see that you've make ' a piece of syntax. OK, I don't think I like
it, but it looks like a consistent revision.

> 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.)

Er ... I forgot that (too much Spice), but please interpret Char as
"integer type representing characters"!
> 
> This might not be what we would want.
 
> 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.

(as in Pepper)
 
> But all the commas that are necessary are ugly. Is there a middle
> ground?

I distinguished quoted and unquoted lists/vectors in Pepper; the quoted
ones don't need commas. Originally I was much more purist, but *writing*
Pepper code cured me of this, at least with respect to list/vector syntax.
 
>   if line matches [== i think i ??text you] then
>       [perhaps you think we ^^text each other?]=>

Leaving aside for the moment that current Pepper doesn't have matches,
nor such free use of `valof`,

    `[== i think i ??text you]`
    `[perhaps you think we ^^text each other?]`

are the equivalent lists. (Yes, ^^ does list splicing. Also in unquoted
context you can do thinks like [x, y, z | somelist] to precatenate x,
y, and z onto somelist.)

> 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?

Defence.

>>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?

Oh yes ... because of the following revealed lie.

>>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 [% ... %]?

Yes. It seems to work well in "practice" (ie the Pepper compiler and the
various bits of code that I write in Pepper to do sundry data hacking
and HTML generation).

>>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

Ulgh. How ... unpleasant. I can see that being the case in C extensions,
but the "multiple values" approach seems much more in the Pop spirit.
(Incidentally, Spice characters are supposed to be 16-bit Unicode, not
ascii).

> [Digression: why doesn't pop11 allow lower case letters in hexadecimal
> constants?]

Yes. Stupid, isn't it. I fixed *that* one in Pepper.
 
> 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'

The Spice operator for this is "...", so you can write

    "a string"...

to explode the string "at run-time". 'a string' does this at compile-time
(and, of course, in quoted contexts: contrast

    `[some '-=09506!!' characters]`
and
    `[some % "-=09506!!".explode % characters]`
or
    [`some`, "-=9506!!".explode, `characters`]

>>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? 

I suspect lots of it, in obscure places. 

> And are there any disadvantages?

Yes.

It makes garbage collection more difficult. For example, a Cheney-style
GC needs to be able to do a linear sweep along moved objects, and to be
able to identify the type of the object given its start. This will cause
problems in the current Pepper implementation when I write the GC (ahem).
It causes problems in the Spice GC because my Spice implementation plays
the same trick with procedures: the "external reference table" comes
before the key. The Spice implementation handles this by planting a
special "skip forward N slots" value in front of moved procedures. 

So words pay a hidden extra slot overhead, or you arrange that all strings
have an unused slot so that they're store-compatible.

-- 
Chris "thought about this lots" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html