Subject: [clisp-list] CHARSET questions & early vs late error signaling

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Mon Aug 12 02:02:02 2002

Hi,

John K. Hinsdale wrote:
>It turns out you can ask Oracle what character set is in force in the
>current database so I guess I put in a check to see if CLISP is using
>ASCII while Oracle is using an 8-bit character set.  Then the problem
>can be detected in advance, giving the hints you mentioned.

I believe you should try to make CLISP match the database's encoding. If you second-guess or hard-code ASCII, such code will not work e.g. in the win32 port where the default encoding could be OLD-DOS (whatever its name), while Oracle would probably use ISO-8859-1.

Bear in mind that current, the CLISP FFI doesn't support multibyte strings, e.g. UTF-16 etc. My FFI add-ons for dealing with that have been put on hold (snice that encoding-trailing-zeroes issue).

>I'm using the FFI::c-string type.
Then custom:*foreign-encoding* is the place to set.

Kaz Kylheku writes:
>I think that this variable is actually a symbol macro, not a special
>variable. It expands to a function call. So you can't give it a dynamic
>binding.

Yes, and I find this fact particularly sad. Compare
(let ((custom:*foreign-encoding* (oracle-db-encoding connection)))
  (foreign-funcall #)) #| sadly does not work |# with:
(let ((old custom:foreign-encoding)
      (new (oracle-db-encoding connection)))
  (unwind-protect
    (progn (setf custom:foreign-encoding new)
           (foreign-funcall #))   
    (setf custom:*foreign-encoding* old)))
Every Common Lisper who sees this would say: Whatzthat?? Unwind-protect to a special variable - looks like a beginner's mistake.

CLISP is inconsistent. More specifically: CLISP has been contributed to by different people with different tradeoffs on this and that, people's opinion also shift over time, and there was never something like a CLISP-philosophy guide.

An example of the opposed philosophies on early or late error signaling:

o custom:*xyz-encoding* are symbol macros, so as to be able to test at setf time the correctness of the values. The drawback is that LET becomes unusable.
o (close #<IO TERMINAL STREAM usually bound to*terminal-io*) is legal and CLISP will not error out until it tries to write to the terminal. This happens obviously soon in an interactive session, but arbitrarily late when running an application. Some people were already hit by erroneous closing of the wrong stream and so looked for the error at the wrong place.
This need not be the case. In my Amiga-CLISP, the low-level close would signal an error on an attempt to close the terminal stream, much like the early *-encoding* check.
Each of these two aspects could have been the other way round.

Well, who cares :-)

Regards,
	Jorg Hohle.

---

From: "John K. Hinsdale" <[email-masked]>
Date: Mon Aug 12 04:49:05 2002

> I believe you should try to make CLISP match the database's
 > encoding. If you second-guess or hard-code ASCII, such code will not
 > work e.g. in the win32 port where the default encoding could be
 > OLD-DOS (whatever its name), while Oracle would probably use
 > ISO-8859-1.

Actually after some more thought I was thinking of trapping just the
specific case of where (a) the current CLISP encoding was ASCII and
(b) the Oracle charset was something anything other than ASCII.  This
should make for a minimum of second guessing on my part.  This library
is mainly for moving back-and-forth and not manipulating it.  I'm also
going to just make it a warning and not an error so that things are
not aborted in the case where there is only ASCII data extant in the
database.

 > Then custom:*foreign-encoding* is the place to set.

OK, I'll mention that in my warning message.

later,

---
John Hinsdale, Alma Mater Software, Inc., Tarrytown, NY 10591-3710 USA
[email-masked] | http://www.alma.com/staff/hin | +1 914 631 4690

---

From: Sam Steingold <[email-masked]>
Date: Mon Aug 12 07:12:06 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] CHARSET questions & early vs late error signaling"
> * Sent on Mon, 12 Aug 2002 11:01:23 +0200
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> CLISP is inconsistent. More specifically: CLISP has been contributed
> to by different people with different tradeoffs on this and that,
> people's opinion also shift over time, and there was never something
> like a CLISP-philosophy guide. 
> 
> o custom:*xyz-encoding* are symbol macros, so as to be able to test at
> setf time the correctness of the values. The drawback is that LET
> becomes unusable.

> o (close #<IO TERMINAL STREAM usually bound to*terminal-io*) is legal
> and CLISP will not error out until it tries to write to the
> terminal. This happens obviously soon in an interactive session, but
> arbitrarily late when running an application. Some people were already
> hit by erroneous closing of the wrong stream and so looked for the
> error at the wrong place.

> This need not be the case. In my Amiga-CLISP, the low-level close
> would signal an error on an attempt to close the terminal stream, much
> like the early *-encoding* check.

there are situations when closing a terminal stream is appropriate,
e.g., when your script is a filter.
we can add a variable, say, CUSTOM:*FORBID-CLOSING-TERMINAL-STREAMS*,
and set it initially to NIL for backward compatibility.
Do people really want that?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Why do we want intelligent terminals when there are so many stupid users?

---

From: Sam Steingold <[email-masked]>
Date: Mon Aug 12 08:43:03 2002

> error at the wrong place.

actually this behavior is mandated by the ANSI CL spec: CLOSE cannot
signal an error.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
"Complete Idiots Guide to Running LINUX Unleashed in a Nutshell for Dummies"