Re: Possible new issue introduced with 20140316 release

Thanks for the feedback.

I think that my original reasoning was probably flawed for trying to seemlessly handle the storage an retreival of lisp symbols to the database.  (Again I was trying to read strings from the database as symbols and store them back as strings, rather than trying to read and write lisp-symbols.)

I think that Matthew Stickney is correct and that we should just call read-from-string on a correctly printed lisp symbol-string.  I still dont know how that will interact if what we actually have stored in the database is a regular, space containing string.  I am guessing it either needs to be an error at building the object (as we would have incorrectly converted that column), or special case code if what we have doesnt appear to be a lisp symbol.

The first step, I guess is to write a bunch of tests cases for each situation and documenting what the current system does.  

I also have a feeling that either I miswrote in my previous email, or there is some conflation between printing symbols to the database when they represent database schema items and when they represent data.  Obviously we will need to print symbols differently if they are in a schema context (ie: refering to a database column) vs symbols in a data context (ie: a string that needs to be inserted).

EG: (sql [= [a.b] 'c]) => "(A.B = C)", which makes not much sense if [a.b] names a "symbol" valued column.  Since this has long been the case, and the oodml layer currently compiles into expressions like this, preserving backward compatibility is going to be tricky.

I will try to devote a bit of time to getting a patch resolving this complete next week (or at least more discussion).

Cheers,
Russ Tyndall
Acceleration.net


-----Original message-----
From: Matthew Stickney [email protected]
Date: Tue, 15 Apr 2014 14:54:53 -0400
To: [email protected]
Subject: Re: [CLSQL] Possible new issue introduced with 20140316 release

On Wed, Apr 9, 2014 at 1:54 PM, Russ Tyndall <[email protected]> wrote:
> The reason to switch to intern, is that intern will always return a symbol where read-from-string could return any valid lisp type.  Read-from-string will also stop reading if it reaches a space while valid symbols may contain spaces.

I'm already late to this party, but I'm voting for using
read-from-string here. As long as you're printing with
*print-readably* t, read-from-string will handle spaces, package
names, things that don't look like symbols, and mixed case (e.g
(make-symbol "1") => #:|1|, (make-symbol "flub") => #:|flub|). If
you're going to roll your own parser, you'll have to take care to deal
with syntax like the | escape, or you may wind up with symbols like
#:|\|foo\||.

It seems to me the easiest and most robust solution is something like:
(let ((o (read-from-string s)))
  (check-type o symbol)
  o)

Then you'd just have to make sure you bind *print-readably* and
*read-eval* on output/input, respectively.

-Matt Stickney
_______________________________________________
CLSQL mailing list
[email protected]
http://lists.b9.com/cgi-bin/mailman/listinfo/clsql