Re: I can't find which line is causing the error

"Geoffrey Summerhayes" <sRuEmMrOnVoEt@xxxxxxxxxxx> writes:

> "Kent M Pitman" <pitman@xxxxxxxxxxx> wrote in message
> news:uhdfi5rhy.fsf@xxxxxxxxxxxxxx
> > "Coby Beck" <cbeck@xxxxxxxxxxxxx> writes:
> >
> >> That is very long and messy code. I tried to auto indent the first defun
> >> and it says unbalanced paren. Clean it up and then look for the
> >> offending
> >> line.
> >
> > But it's a classic. This remark is a bit like telling someone to sharpen
> > the focus on a Monet...
> >
> > Probably modern indenting tools don't work because of the use of / as a
> > syntactic quoting element. On a quick look, it seems balanced to me.
> > I suspect he has " defined as a readmacro, which wasn't true in the early
> > days of MACLISP when SHRDLU was written, but was true in later MACLISP
> > such as is running on the emulators. Easy enough to fix by undefining
> > the readmacro or else slashing the doublequotes.
> >
>
> Just curious, did it have strings as a datatype and if so how did it handle
> them without a " readmacro?

No, there's no primitive string datatype in MACLISP. Symbols were used
instead. Symbols could be compared for SAMEPNAMEP and various people had
syntactic sugar on this to make it seem more like there were strings. But
(princ '|foo|) was as likely to be done as (princ "foo") since most people
didn't trust the later to work. There were two competing string packages:

"fake strings" just made an uninterned symbol (so it would get gc'd if
discarded) that had itself as a value and that would print with "'s
around it. there were no serious operations on fake strings other than
to print them or concatenate them, but you could fake it with
explode, implode, samepnamep, etc. You'd think these things were too
slow, being O(n) rather than O(1) for access, since pnames were stored
as lists of integers, each integer being a 36 bit word that held 5
seven-bit characters with one bit left over. But in practice, since
most applications didn't do heavy character-level operations, and were
mostly using strings just for static messages, this didn't come up.
Also, big-O notation only makes sense in the limit, but on the PDP10,
other limits hit you first--like a 256 Kword address space, keeping those
big-O-ignored constant factors quite prominent.

"real strings" had more overhead that i think most people thought to be
overkill. they were not symbols. there were theoretical reasons why you
might want real strings if you were making a text editor or something to
do heavy string operations, but most people didn't do such things. for
most light programming, "fake strings" were adequate.

.