Hi,

I and a few other Turkish programmers are in
the process of indoctrinating young souls with Lispology.

Currently we're trying to convert lisperati by Conrad Barski, M.D.
(http://lisperati.com) into Turkish. I have the
task of converting bits and pieces of Lisp code into Turkish.
I have finished %90 of it however there is an important
thing to do: When I run the code it prints the sentences
one word/line. I think this is because they are given as lists,
but I'm not sure, since I'm also a Lisp beginner I'd like
to learn if there's way to put them/print them
in a single line.

You can see what I mean if you look at the short & complete
lisp code at http://lisperati.com/code.html

Or if you are lazy, here's a sample Turkish interactive
session with lisperati code (in Turkish), as you can see
a little bit ugly output, I need them more than a few words/line format
without touching the code too much (for pedagocical reasons):

CL-USER> (bak)
(|BüYüCüNüN| EVINDEKI
BIR
OTURMA
ODASINDASINIZ.
KANEPEDE
HORUL
HORUL
UYUYAN
BIR
|BüYüCü|
VAR.
BATI
ILE
KAPI
ARASINDA
BIR
YOL
VAR.
USTKAT
ILE
MERDIVEN
ARASINDA
BIR
YOL
VAR.
ZEMINDE
BIR
VISKI-SISESI
|GöRüYORSUNUZ.|
ZEMINDE
BIR
KOVA
|GöRüYORSUNUZ.|)
CL-USER>

--
Emre Sevinc

eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr

From:	Thomas A. Russ
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	21 Jan 2005 13:33:12 -0800

Pascal Bourguignon writes:

> Emre Sevinc writes:
> > Another curiosity is that when I use some symbol names that
> > included some Turkish letters in them, SBCL puts them between
> >
> > |...|
> >
> > I don't know what those bars used in context of CL. Why do we
> > need them when SBCL prints some symbol that includes some non-English
> > letters? I did not use vertical bars in the code and SBCL
> > did not complain (unless the letter was the first letter of
> > the symbol) but it uses that strange looking format to print
> > them.
>
> This is an escape mechanism that allows to read symbols
> containing characters that are not constituent characters.
>
> '|Hello World!| --> |Hello World!|
> 'Hello\ World! --> |HELLO WORLD!| ; according to the
> 'Hello-World! --> HELLO-WORLD! ; default readtable case.

But going back to the original poster's question, I suspect that it is
just a quirk of the printing routines that notice a non-standard
character in the symbol name and decide to put the vertical bars around
the printed symbol just to be on the safe side.

My guess is that it is just a consequence of not noticing this
particular interaction when dealing with character sets beyond the
standard ASCII.

Although slightly ugly, there is no bad effect of having the extra
vertical bars present when they don't have to be there.

'|FOOBAR| => FOOBAR

without any real problems.

--
Thomas A. Russ, USC/Information Sciences Institute

From:	Pascal Bourguignon
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	22 Jan 2005 00:39:46 +0100

tar@sevak.isi.edu (Thomas A. Russ) writes:

> Pascal Bourguignon writes:
>
> > Emre Sevinc writes:
> > > Another curiosity is that when I use some symbol names that
> > > included some Turkish letters in them, SBCL puts them between
> > >
> > > |...|
> > >
> > > I don't know what those bars used in context of CL. Why do we
> > > need them when SBCL prints some symbol that includes some non-English
> > > letters? I did not use vertical bars in the code and SBCL
> > > did not complain (unless the letter was the first letter of
> > > the symbol) but it uses that strange looking format to print
> > > them.
> >
> > This is an escape mechanism that allows to read symbols
> > containing characters that are not constituent characters.
> >
> > '|Hello World!| --> |Hello World!|
> > 'Hello\ World! --> |HELLO WORLD!| ; according to the
> > 'Hello-World! --> HELLO-WORLD! ; default readtable case.
>
> But going back to the original poster's question, I suspect that it is
> just a quirk of the printing routines that notice a non-standard
> character in the symbol name and decide to put the vertical bars around
> the printed symbol just to be on the safe side.

No. It is a standard specified escape mechanism that allows to read
symbols containing characters that _are_ _not_ _constituent_ _characters_.

--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"

From:	Thomas A. Russ
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	21 Jan 2005 13:38:15 -0800

Pascal Bourguignon writes:

> Note that you should probably not use TPL. If *PRINT-LENGTH* is
> defined in TLP, t's probably this same symbol that is reexported from
> COMMON-LISP.
>
> (setf *print-length* nil)

Actually it isn't. It one of a couple separate variables used in
Allegro lisp to give a separate set of printer control variables to be
used by the toplevel read-eval-print loop as distinct from any other
printing that may be going on. Although not privy to the details, I
assume that the process ends up something like this code fragment:

(let ((value (eval (read))))
(let ((*print-length* tpl:*print-length*))
(print value))))

Here are some examples from Allego:

USER> *print-length*
()
USER> tpl:*print-length*
10
USER> '(1 2 3 4 5 6 7 8 9 10 11 12 13)
(1 2 3 4 5 6 7 8 9 10 ...)
USER> (print '(1 2 3 4 5 6 7 8 9 10 11 12 13))

(1 2 3 4 5 6 7 8 9 10 11 12 13)
(1 2 3 4 5 6 7 8 9 10 ...)

--
Thomas A. Russ, USC/Information Sciences Institute

From:	Carl Shapiro
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	19 Jan 2005 04:40:10 -0500

Emre Sevinc writes:

> Or if you are lazy, here's a sample Turkish interactive
> session with lisperati code (in Turkish), as you can see
> a little bit ugly output, I need them more than a few words/line format
> without touching the code too much (for pedagocical reasons):
>
> CL-USER> (bak)
> (|BüYüCüNüN| EVINDEKI

....

> |GöRüYORSUNUZ.|)
> CL-USER>

This is most likely a consequence of the Common Lisp pretty printer.
Try evaluating "(let ((*print-pretty* nil)) (bak))". Alternatively,
you could "(setq *print-pretty* nil)" and then evaluate "(bak)". This
should probably be done along with the adjustment to *print-length* at
the top of .

From:	Emre Sevinc
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Thu, 20 Jan 2005 19:02:38 +0200

Pascal Bourguignon writes:

> Emre Sevinc writes:
>
>> Pascal Bourguignon writes:
>>
>> > Emre Sevinc writes:
>> >> On the other hand when I removed tpl: from it and tried in
>> >> my SBCL:
>> >>
>> >> ;; TPL package exists only in Franz Allegro CL
>>[..]
>> Now I'm in the process of trying to understand the subtle
>> differences between SETF and SETQ, I'm digging into HyperSpec
>> and CLtL but I'd be glad if somebody can put statements like
>> "never ever use SETF for these situations" and "never ever commit
>> the crime of using SETQ for these purposes", etc. ;-)
>
> There's no difference between:
>
> (SETF symbol value)
> and: (SETQ symbol value)
>
> (macroexpand '(setf symbol value)) --> (SETQ SYMBOL VALUE)
>
>
> But SETQ can only assign a symbol, while SETF can also assign other
> kind of places:
>
> (SETF (CAR (AREF array 3)) value)
>
> (defvar example)
> (SETF (documentation 'example 'variable) "This a sample variable")
>

Now it's crystal clear. Since SETF is macroexpanded I think
I must prefer SETQ for simple symbol assignment.

--
Emre Sevinc

eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr

From:	Brian Downing
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Thu, 20 Jan 2005 18:17:35 GMT

In article <87fz0wowy9.fsf@ileriseviye.org>,
Emre Sevinc wrote:
> Pascal Bourguignon writes:
> > There's no difference between:
> >
> > (SETF symbol value)
> > and: (SETQ symbol value)
> >
> > (macroexpand '(setf symbol value)) --> (SETQ SYMBOL VALUE)
> >
> >
> > But SETQ can only assign a symbol, while SETF can also assign other
> > kind of places:
> >
> > (SETF (CAR (AREF array 3)) value)
> >
> > (defvar example)
> > (SETF (documentation 'example 'variable) "This a sample variable")
>
> Now it's crystal clear. Since SETF is macroexpanded I think
> I must prefer SETQ for simple symbol assignment.

Keep in mind that SETQ has a backdoor - if assigning a symbol-macro, it
will magically change to a SETF behind the scenes.

So:

(let ((thing (cons 'a 'b)))
(symbol-macrolet ((frob (car thing)))
(setq frob 'frobbed)
thing))
=> (FROBBED . B)

So if you're preferring SETQ because it has some sort of complexity
guarantee vs. SETF, it doesn't.

(Personally, I always use SETF.)

-bcd
--
*** Brian Downing

From:	John Thingstad
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Thu, 20 Jan 2005 19:29:25 +0100

On Thu, 20 Jan 2005 19:02:38 +0200, Emre Sevinc wrote:

>
> Now it's crystal clear. Since SETF is macroexpanded I think
> I must prefer SETQ for simple symbol assignment.
>

??
By now it should be obvious that setq is there for historical
reasons.. For consistency it would be better to rely on setf.

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

From:	Christopher C. Stacy
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Thu, 20 Jan 2005 21:03:01 GMT

"John Thingstad" writes:

> On Thu, 20 Jan 2005 19:02:38 +0200, Emre Sevinc wrote:
>
> >
> > Now it's crystal clear. Since SETF is macroexpanded I think
> > I must prefer SETQ for simple symbol assignment.
> >
>
> ??
> By now it should be obvious that setq is there for historical
> reasons.. For consistency it would be better to rely on setf.

I use SETQ to indicate to other programmers that I am setting
a completely ordinary variable, as opposed to any other "place".

From:	Peter Seibel
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Fri, 21 Jan 2005 18:18:01 GMT

Jurn Franken writes:

>> Peter Seibel wrote:
>> FWIW, many folks consider it "modern" style to use SETF for all
>> assignments--exactly because it is macro expanded there's no runtime
>> cost. Thus:
>> (setf foo 10) rather than (setq foo 10)
>> (setf (car list) 'x) rather than (rplaca list 'x)
>> (setf (values x y z) 1 2 3) rather than (multiple-value-setq (x y z) 1 2 3)
>> etc.
>> -Peter
>>
>
> Shouldn't: (setf (values x y z) 1 2 3)
> be: (setf (values x y z) (values 1 2 3)) ?

> I get an error with the original.

Er, yes. Sorry. Likewise in the MULTIPLE-VALUE-SETQ version.

-Peter

--
Peter Seibel peter@javamonkey.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

From:	John Thingstad
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Fri, 21 Jan 2005 19:58:55 +0100

On Fri, 21 Jan 2005 18:18:01 GMT, Peter Seibel
wrote:

> Jurn Franken writes:
>
>>> Peter Seibel wrote:
>>> FWIW, many folks consider it "modern" style to use SETF for all
>>> assignments--exactly because it is macro expanded there's no runtime
>>> cost. Thus:
>>> (setf foo 10) rather than (setq foo 10)
>>> (setf (car list) 'x) rather than (rplaca list 'x)
>>> (setf (values x y z) 1 2 3) rather than (multiple-value-setq (x y z)
>>> 1 2 3)
>>> etc.
>>> -Peter
>>>
>>
>> Shouldn't: (setf (values x y z) 1 2 3)
>> be: (setf (values x y z) (values 1 2 3)) ?
>
>> I get an error with the original.
>
> Er, yes. Sorry. Likewise in the MULTIPLE-VALUE-SETQ version.
>
> -Peter
>

Or just (setf x 1 y 2 z 3) ;)

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

From:	Pascal Bourguignon
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	19 Jan 2005 19:23:26 +0100

Carl Shapiro writes:

> Emre Sevinc writes:
>
> > Or if you are lazy, here's a sample Turkish interactive
> > session with lisperati code (in Turkish), as you can see
> > a little bit ugly output, I need them more than a few words/line format
> > without touching the code too much (for pedagocical reasons):
> >
> > CL-USER> (bak)
> > (|BüYüCüNüN| EVINDEKI
>
> ...
>
> > |GöRüYORSUNUZ.|)
> > CL-USER>
>
> This is most likely a consequence of the Common Lisp pretty printer.
> Try evaluating "(let ((*print-pretty* nil)) (bak))".

*PRINT-PRETTY* applies only to PRINT, not to result of a LET!

(let ((*print-pretty* nil)) (print (bak)))

will print the result of bak on a line, and will return this result,
which will be printed by the REPL with the saved value of
*PRINT-PRETTY*.

(let ((*print-pretty* nil)) (print (bak)) (values))

> Alternatively,
> you could "(setq *print-pretty* nil)" and then evaluate "(bak)". This
> should probably be done along with the adjustment to *print-length* at
> the top of .

For sentences, I'd use rather: (format t "~&~{~A~^ ~}~%" (bak))

--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.

From:	Peter Seibel
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Thu, 20 Jan 2005 18:01:48 GMT

Emre Sevinc writes:

> Pascal Bourguignon writes:
>
>> Emre Sevinc writes:
>>
>>> Pascal Bourguignon writes:
>>>
>>> > Emre Sevinc writes:
>>> >> On the other hand when I removed tpl: from it and tried in
>>> >> my SBCL:
>>> >>
>>> >> ;; TPL package exists only in Franz Allegro CL
>>>[..]
>>> Now I'm in the process of trying to understand the subtle
>>> differences between SETF and SETQ, I'm digging into HyperSpec
>>> and CLtL but I'd be glad if somebody can put statements like
>>> "never ever use SETF for these situations" and "never ever commit
>>> the crime of using SETQ for these purposes", etc. ;-)
>>
>> There's no difference between:
>>
>> (SETF symbol value)
>> and: (SETQ symbol value)
>>
>> (macroexpand '(setf symbol value)) --> (SETQ SYMBOL VALUE)
>>
>>
>> But SETQ can only assign a symbol, while SETF can also assign other
>> kind of places:
>>
>> (SETF (CAR (AREF array 3)) value)
>>
>> (defvar example)
>> (SETF (documentation 'example 'variable) "This a sample variable")
>>
>
> Now it's crystal clear. Since SETF is macroexpanded I think
> I must prefer SETQ for simple symbol assignment.

FWIW, many folks consider it "modern" style to use SETF for all
assignments--exactly because it is macro expanded there's no runtime
cost. Thus:

(setf foo 10) rather than (setq foo 10)
(setf (car list) 'x) rather than (rplaca list 'x)
(setf (values x y z) 1 2 3) rather than (multiple-value-setq (x y z) 1 2 3)
etc.

-Peter

--
Peter Seibel peter@javamonkey.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

From:	Jurn Franken
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Fri, 21 Jan 2005 14:18:13 +0100

> Peter Seibel wrote:
>
> FWIW, many folks consider it "modern" style to use SETF for all
> assignments--exactly because it is macro expanded there's no runtime
> cost. Thus:
>
> (setf foo 10) rather than (setq foo 10)
> (setf (car list) 'x) rather than (rplaca list 'x)
> (setf (values x y z) 1 2 3) rather than (multiple-value-setq (x y z) 1 2 3)
> etc.
>
> -Peter
>

Shouldn't: (setf (values x y z) 1 2 3)
be: (setf (values x y z) (values 1 2 3)) ?

I get an error with the original.

Jurn

From:	Emre Sevinc
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Thu, 20 Jan 2005 09:30:01 +0200

Carl Shapiro writes:

> Emre Sevinc writes:
>
>> Thanks for showing me how to do it. Actually, the original
>> lisperati is assumed to be run on Franz's telnet server
>> serving a CL envrionment, so that people can give it a try
>> without installing anything at all on their machines. However
>> since I've recently published a Turkish article about how to
>> install Emacs+SLIME+SBCL I want the code to run in that
>> environment, too, without any problems or ugly output. I had
>> to comment out the line related to TPL because my SBCL
>> environment complained:
>
> The TPL package exists only in Allegro Common Lisp. You can safely
> remove the "tpl:" before *print-length* to achieve the desired effect.
> There ought to be a comment about this in the source code you are
> looking at, especially since it is targeted to Lisp newcomers.

Thanks for the extra explanation. I'll draw attention to this
point so the new Lispers will know what it is about. However there
is not much comment about it in the source code, the author assumes
everybody will use the Franz telnet server based CL.

On the other hand when I removed tpl: from it and tried in
my SBCL:

;; TPL package exists only in Franz Allegro CL
;;(defparameter tpl:*print-length* nil)

;; So let's not use TPL - OOPS, Package Lock Error!
(defparameter *print-length* nil)

I was given the following erro:

Lock on package COMMON-LISP violated when globally declaring *PRINT-LENGTH*
special.
[Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]

See also:
SBCL Manual, Package Locks [node]
Common Lisp Hyperspec, 11.1.2.1.2 [section]

Maybe it is better to completely forget about that line because
I've already had the effect I wanted.

--
Emre Sevinc

eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr

From:	Pascal Bourguignon
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	20 Jan 2005 09:14:27 +0100

Emre Sevinc writes:
> On the other hand when I removed tpl: from it and tried in
> my SBCL:
>
> ;; TPL package exists only in Franz Allegro CL
> ;;(defparameter tpl:*print-length* nil)
>
> ;; So let's not use TPL - OOPS, Package Lock Error!
> (defparameter *print-length* nil)
>
>
> I was given the following erro:
>
> Lock on package COMMON-LISP violated when globally declaring *PRINT-LENGTH*
> special.
> [Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]

Yes of course.

SETF has no defined effect when the symbol you're trying to assign to
is not defined, but when you're assigning to a symbol that's already
defined somewhere, SETF has a perfectly well defined effect.

On the other hand, since programmers should not modify the _symbols_
in the COMMON-LISP package, implementers invented package locks to
warn against it, therefore a DEFPARAMETER on a symbol already defined
in a locked package won't work. Use SETF !

Note that you should probably not use TPL. If *PRINT-LENGTH* is
defined in TLP, t's probably this same symbol that is reexported from
COMMON-LISP.

(setf *print-length* nil)

--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.

From:	Emre Sevinc
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Thu, 20 Jan 2005 10:45:16 +0200

Pascal Bourguignon writes:

> Emre Sevinc writes:
>> On the other hand when I removed tpl: from it and tried in
>> my SBCL:
>>
>> ;; TPL package exists only in Franz Allegro CL
>> ;;(defparameter tpl:*print-length* nil)
>>
>> ;; So let's not use TPL - OOPS, Package Lock Error!
>> (defparameter *print-length* nil)
>>
>>
>> I was given the following erro:
>>
>> Lock on package COMMON-LISP violated when globally declaring *PRINT-LENGTH*
>> special.
>> [Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]
>
> Yes of course.
>
> SETF has no defined effect when the symbol you're trying to assign to
> is not defined, but when you're assigning to a symbol that's already
> defined somewhere, SETF has a perfectly well defined effect.
>
> On the other hand, since programmers should not modify the _symbols_
> in the COMMON-LISP package, implementers invented package locks to
> warn against it, therefore a DEFPARAMETER on a symbol already defined
> in a locked package won't work. Use SETF !

Thanks for enlightening me.

Now I'm in the process of trying to understand the subtle
differences between SETF and SETQ, I'm digging into HyperSpec
and CLtL but I'd be glad if somebody can put statements like
"never ever use SETF for these situations" and "never ever commit
the crime of using SETQ for these purposes", etc. ;-)

Another curiosity is that when I use some symbol names that
included some Turkish letters in them, SBCL puts them between

|...|

I don't know what those bars used in context of CL. Why do we
need them when SBCL prints some symbol that includes some non-English
letters? I did not use vertical bars in the code and SBCL
did not complain (unless the letter was the first letter of
the symbol) but it uses that strange looking format to print
them.

--
Emre Sevinc

eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr

From:	Pascal Bourguignon
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	20 Jan 2005 10:31:03 +0100

Emre Sevinc writes:

> Pascal Bourguignon writes:
>
> > Emre Sevinc writes:
> >> On the other hand when I removed tpl: from it and tried in
> >> my SBCL:
> >>
> >> ;; TPL package exists only in Franz Allegro CL
> >> ;;(defparameter tpl:*print-length* nil)
> >>
> >> ;; So let's not use TPL - OOPS, Package Lock Error!
> >> (defparameter *print-length* nil)
> >>
> >>
> >> I was given the following erro:
> >>
> >> Lock on package COMMON-LISP violated when globally declaring *PRINT-LENGTH*
> >> special.
> >> [Condition of type SYMBOL-PACKAGE-LOCKED-ERROR]
> >
> > Yes of course.
> >
> > SETF has no defined effect when the symbol you're trying to assign to
> > is not defined, but when you're assigning to a symbol that's already
> > defined somewhere, SETF has a perfectly well defined effect.
> >
> > On the other hand, since programmers should not modify the _symbols_
> > in the COMMON-LISP package, implementers invented package locks to
> > warn against it, therefore a DEFPARAMETER on a symbol already defined
> > in a locked package won't work. Use SETF !
>
> Thanks for enlightening me.
>
> Now I'm in the process of trying to understand the subtle
> differences between SETF and SETQ, I'm digging into HyperSpec
> and CLtL but I'd be glad if somebody can put statements like
> "never ever use SETF for these situations" and "never ever commit
> the crime of using SETQ for these purposes", etc. ;-)

There's no difference between:

(SETF symbol value)
and: (SETQ symbol value)

(macroexpand '(setf symbol value)) --> (SETQ SYMBOL VALUE)

But SETQ can only assign a symbol, while SETF can also assign other
kind of places:

(SETF (CAR (AREF array 3)) value)

(defvar example)
(SETF (documentation 'example 'variable) "This a sample variable")

> Another curiosity is that when I use some symbol names that
> included some Turkish letters in them, SBCL puts them between
>
> |...|
>
> I don't know what those bars used in context of CL. Why do we
> need them when SBCL prints some symbol that includes some non-English
> letters? I did not use vertical bars in the code and SBCL
> did not complain (unless the letter was the first letter of
> the symbol) but it uses that strange looking format to print
> them.

This is an escape mechanism that allows to read symbols
containing characters that are not constituent characters.

'|Hello World!| --> |Hello World!|
'Hello\ World! --> |HELLO WORLD!| ; according to the
'Hello-World! --> HELLO-WORLD! ; default readtable case.

--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.

From:	Emre Sevinc
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	Wed, 19 Jan 2005 12:08:04 +0200

Carl Shapiro writes:

> Emre Sevinc writes:
>
>> Or if you are lazy, here's a sample Turkish interactive
>> session with lisperati code (in Turkish), as you can see
>> a little bit ugly output, I need them more than a few words/line format
>> without touching the code too much (for pedagocical reasons):
>>
>> CL-USER> (bak)
>> (|BüYüCüNüN| EVINDEKI
>
> ...
>
>> |GöRüYORSUNUZ.|)
>> CL-USER>
>
> This is most likely a consequence of the Common Lisp pretty printer.
> Try evaluating "(let ((*print-pretty* nil)) (bak))". Alternatively,
> you could "(setq *print-pretty* nil)" and then evaluate "(bak)". This
> should probably be done along with the adjustment to *print-length* at
> the top of .

Thanks for showing me how to do it. Actually, the original
lisperati is assumed to be run on Franz's telnet server
serving a CL envrionment, so that people can give it a try
without installing anything at all on their machines. However
since I've recently published a Turkish article about how to
install Emacs+SLIME+SBCL I want the code to run in that
environment, too, without any problems or ugly output. I had
to comment out the line related to TPL because my SBCL
environment complained:

READER-ERROR at 32 (line 1, column 32) on #:
package "TPL" not found
[Condition of type SB-KERNEL:READER-PACKAGE-ERROR]

However your solution worked and I had the many symbols/per line
effect I was looking for.

Thanks.

--
Emre Sevinc

eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr

From:	Carl Shapiro
Subject:	Re: lisperati: All symbols in one line instead of one symbol/line
Date:	19 Jan 2005 13:33:08 -0500

Emre Sevinc writes:

> Thanks for showing me how to do it. Actually, the original
> lisperati is assumed to be run on Franz's telnet server
> serving a CL envrionment, so that people can give it a try
> without installing anything at all on their machines. However
> since I've recently published a Turkish article about how to
> install Emacs+SLIME+SBCL I want the code to run in that
> environment, too, without any problems or ugly output. I had
> to comment out the line related to TPL because my SBCL
> environment complained:

The TPL package exists only in Allegro Common Lisp. You can safely
remove the "tpl:" before *print-length* to achieve the desired effect.
There ought to be a comment about this in the source code you are
looking at, especially since it is targeted to Lisp newcomers.