I'm a little unclear on this. If I enable bracket mode in the reader,
do I need to use CLSQL in object-oriented mode, where my tables and
rows are classes?
I was hoping to just generate straight sql queries in bracket mode and
get the results as a list of selected columns.
"Jonathon McKitrick" <···········@bigfoot.com> writes:
> I was hoping to just generate straight sql queries in bracket mode and
> get the results as a list of selected columns.
You can do this by explicitly listing the names of the fields you want:
(clsql:locally-enable-sql-reader-syntax)
(clsql:select [timestamp][value] :from [statistics] :limit 3 :flatp t :field-names nil)
=> (("2005-08-20 22:15:14" 110) ("2005-08-22 13:34:43" 110)
("2005-08-22 15:10:26" 111))
Or even
(clsql:select [*] :from [statistics] :limit 3 :flatp t :field-names nil)
As supposed to getting the instances:
(clsql:select 'statistics :limit 3 :flatp t :field-names nil)
=> (#<STATISTICS {594A4DCD}> #<STATISTICS {594A5385}> #<STATISTICS {594A593D}>)
Also check out the CLSQL mailing lists at:
http://clsql.b9.com/maillists.html
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Petter Gustad wrote:
> Or even
>
> (clsql:select [*] :from [statistics] :limit 3 :flatp t :field-names nil)
The [*] does not compile, and I can't get past that part. Even with
the
locally-enable-sql-reader-syntax declaration at the beginning of the
function.
"Jonathon McKitrick" <···········@bigfoot.com> wrote in message
·····························@o13g2000cwo.googlegroups.com...
>
> Petter Gustad wrote:
>> Or even
>>
>> (clsql:select [*] :from [statistics] :limit 3 :flatp t :field-names nil)
>
> The [*] does not compile, and I can't get past that part. Even with
> the
> locally-enable-sql-reader-syntax declaration at the beginning of the
> function.
Show some code!
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Asbjørn Bjørnstad wrote:
> Try:
> (clsql:locally-enable-sql-reader-syntax)
> (defun whatever)
> (clsql:locally-disable-sql-reader-syntax)
That did it! Thanks.
Damn, I love this language....
From: =?utf-8?b?QXNiasO4cm4gQmrDuHJuc3Q=?= =?utf-8?b?YWQ=?=
Subject: Re: Problem enabling bracket mode it CLSQL
Date:
Message-ID: <5o3bjgkait.fsf@kolme.ifi.uio.no>
···@while.it.lasted.invalid (Asbjørn Bjørnst writes:
> "Jonathon McKitrick" <···········@bigfoot.com> writes:
>
> > Coby Beck wrote:
> > > Show some code!
> >
> > Sorry!
> >
> >
> > (defun bracket-query-interests ()
> > (clsql:locally-enable-sql-reader-syntax)
> > (let (interests)
> > (setf interests (subseq (first (clsql:select [*] :from [birkman]
> > :flatp t :field-names nil)) 3 13))))
>
> locally-enable-sql-syntax shoul not be part of the function, I think.
>
> Try:
> (clsql:locally-enable-sql-reader-syntax)
> (defun whatever)
> (clsql:locally-disable-sql-reader-syntax)
BTW. The reason is that locally-enable-sql-reader-syntax is changing
the reader. Since the reader will read in the whole defun form before
evaluating it, it is too late to do the call inside the defun. The reader
has already processed your [*] so changing the syntax will not work.
I think.
--
-asbjxrn
<·······@ifi.uio.no> wrote:
+---------------
| BTW. The reason is that locally-enable-sql-reader-syntax is changing
| the reader. Since the reader will read in the whole defun form before
| evaluating it, it is too late to do the call inside the defun. The reader
| has already processed your [*] so changing the syntax will not work.
+---------------
And if file-compiling it, the OP'll probably need an EVAL-WHEN wrapped
around them, too...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> And if file-compiling it, the OP'll probably need an EVAL-WHEN wrapped
> around them, too...
When, in general, do you *not* want EVAL-WHEN wrapped around a reader
macro call?
Jonathon McKitrick <···········@bigfoot.com> wrote:
+---------------
| Rob Warnock wrote:
| > And if file-compiling it, the OP'll probably need an EVAL-WHEN wrapped
| > around them, too...
|
| When, in general, do you *not* want EVAL-WHEN wrapped around a reader
| macro call?
+---------------
Whenever you want the reader macro to apply only to a stream which
is *not* the current source text file, e.g.:
(let ((save (get-dispatch-macro-character #\# #\$)))
(unwind-protect
(progn (set-dispatch-macro-character #\# #\$ #'my-dollar-reader)
(read SOME-STREAM))
(set-dispatch-macro-character #\# #\$ save)))
==> #<a form read from SOME-STREAM with #$ syntax active>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Rob Warnock" <····@rpw3.org> wrote in message
···························@speakeasy.net...
> <·······@ifi.uio.no> wrote:
> +---------------
> | BTW. The reason is that locally-enable-sql-reader-syntax is changing
> | the reader. Since the reader will read in the whole defun form before
> | evaluating it, it is too late to do the call inside the defun. The
> reader
> | has already processed your [*] so changing the syntax will not work.
> +---------------
>
> And if file-compiling it, the OP'll probably need an EVAL-WHEN wrapped
> around them, too...
I don't think so, but I am not a language lawyer.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Coby Beck <·····@mercury.bc.ca> wrote:
+---------------
| "Rob Warnock" <····@rpw3.org> wrote:
| > <·······@ifi.uio.no> wrote:
| > +---------------
| > | Since the reader will read in the whole defun form before evaluating
| > | it, it is too late to do the call inside the defun. The reader has
| > | already processed your [*] so changing the syntax will not work.
| > +---------------
| >
| > And if file-compiling it, the OP'll probably need an EVAL-WHEN wrapped
| > around them, too...
|
| I don't think so, but I am not a language lawyer.
+---------------
Oh, yes, you definitely *do* need the EVAL-WHEN![1] I got burned by
that once very early after starting to use CL. Remember, the source
code gets read in the compile-time environment, which means that the
reader macro must have been enabled in the compile-time environment
*before* any forms using the special syntax are READ from the source
file by the file compiler.
Note that this also means that not only does the form which enables
the syntax need to be in an EVAL-WHEN, but also that you need to
make sure that the function which *implements* the special syntax
needs to be LOADed (or REQUIREd) into the compile-time environment[2],
and that LOAD (or REQUIRE) will itself need to be wrapped in EVAL-WHEN.
-Rob
[1] Well, unless you deliberately "pollute" the compile-time environment
by enabling the syntax *before* calling* COMPILE-FILE, depending
on the current *READTABLE* to be used when reading the file to be
compiled. Some implementations allow such deliberate "leakage"
[e.g., CMUCL -- I just tried it], but AFAICT the CLHS says nothing
about the subject, which means one can probably not depend on it
in general.
[2] Well, unless said function is a literal in the enabling form.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Rob Warnock" <····@rpw3.org> wrote in message
···························@speakeasy.net...
> Coby Beck <·····@mercury.bc.ca> wrote:
> +---------------
> | "Rob Warnock" <····@rpw3.org> wrote:
> | > <·······@ifi.uio.no> wrote:
> | > +---------------
> | > | Since the reader will read in the whole defun form before evaluating
> | > | it, it is too late to do the call inside the defun. The reader has
> | > | already processed your [*] so changing the syntax will not work.
> | > +---------------
> | >
> | > And if file-compiling it, the OP'll probably need an EVAL-WHEN wrapped
> | > around them, too...
> |
> | I don't think so, but I am not a language lawyer.
> +---------------
>
> Oh, yes, you definitely *do* need the EVAL-WHEN![1] I got burned by
> that once very early after starting to use CL. Remember, the source
> code gets read in the compile-time environment, which means that the
> reader macro must have been enabled in the compile-time environment
> *before* any forms using the special syntax are READ from the source
> file by the file compiler.
Yes, you're absolutely correct as a quick look at "3.2.3 File Compilation"
or a small amount of thought confirms. I was reaching for a counter example
in some code I work with that was written by Kent Pitman, who would know of
course, but it was just a macro hiding the eval-when stuff. Interestingly
enough, this macro has a conditional in it so that in the clisp environment
the eval-when is not there..?
(defmacro in-query-syntax ()
#+lispworks`(eval-when (:execute :compile-toplevel :load-toplevel)
(setq *readtable* *query-readtable*)
nil)
#-lispworks(progn (setq *readtable* *query-readtable*)
nil))
Now one must wonder why that works in clisp. Oh, never mind, the macro
expansion executes the code, not returns it.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
On Sun, 22 Jan 2006 08:05:30 +0100, "Asbj�rn Bj�rnst"ad
<···@while.it.lasted.invalid> wrote:
> ···@while.it.lasted.invalid (Asbj�rn Bj�rnst writes:
>
>> "Jonathon McKitrick" <···········@bigfoot.com> writes:
>>
>> > Coby Beck wrote:
>> > > Show some code!
>> >
>> > Sorry!
>> >
>> >
>> > (defun bracket-query-interests ()
>> > (clsql:locally-enable-sql-reader-syntax)
>> > (let (interests)
>> > (setf interests (subseq (first (clsql:select [*] :from [birkman]
>> > :flatp t :field-names nil)) 3 13))))
>>
>> locally-enable-sql-syntax shoul not be part of the function, I think.
>>
>> Try:
>> (clsql:locally-enable-sql-reader-syntax)
>> (defun whatever)
>> (clsql:locally-disable-sql-reader-syntax)
>
> BTW. The reason is that locally-enable-sql-reader-syntax is changing
> the reader. Since the reader will read in the whole defun form before
> evaluating it, it is too late to do the call inside the defun. The reader
> has already processed your [*] so changing the syntax will not work.
>
> I think.
This makes no sense.
The reader changes the way the lexer processes token AS it
reads. Behold
Error while reading: Subcharacter #\" not defined for dispatch char #\#.
CL-USER 1 > #"
Comes up AS I type " not after I finished typing the expression.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Sun, 22 Jan 2006 11:53:28 +0100, John Thingstad
<··············@chello.no> wrote:
> On Sun, 22 Jan 2006 08:05:30 +0100, "Asbj�rn Bj�rnst"ad
>
> This makes no sense.
> The reader changes the way the lexer processes token AS it
> reads. Behold
>
> Error while reading: Subcharacter #\" not defined for dispatch char #\#.
>
> CL-USER 1 > #"
>
> Comes up AS I type " not after I finished typing the expression.
>
OH! I see what you mean.
(clsql:locally-enable-sql-reader-syntax)
isn't seen until after the function is read.
Or rather it wouldn't be if the parser didn't barf.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
+ "John Thingstad" <··············@chello.no>:
| On Sun, 22 Jan 2006 08:05:30 +0100, "Asbj�rn Bj�rnst"ad
| <···@while.it.lasted.invalid> wrote:
|
|>> > (defun bracket-query-interests ()
|>> > (clsql:locally-enable-sql-reader-syntax)
|>> > (let (interests)
|>> > (setf interests (subseq (first (clsql:select [*] :from [birkman]
|>> > :flatp t :field-names nil)) 3 13))))
|>
|> BTW. The reason is that locally-enable-sql-reader-syntax is changing
|> the reader. Since the reader will read in the whole defun form before
|> evaluating it, it is too late to do the call inside the defun. The reader
|> has already processed your [*] so changing the syntax will not work.
|>
|> I think.
|
| This makes no sense.
Sure, it does.
| The reader changes the way the lexer processes token AS it reads.
Uh, your example (elided) only shows that the reader's notion of
acceptable input is different just after reading a # character. How
is that relevant to the case at hand?
Now, if the code above had contained
#.(clsql:locally-enable-sql-reader-syntax) instead of what it does
contain, then it might have worked. But it seems that the problem
here is a misunderstanding of what locally-enable-sql-reader-syntax
does: It is not intended to limit the use of alternate syntax to a
single form, as the writer of the above code seems to believe.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
""Asbj�rn Bj�rnst" "ad"" <···@while.it.lasted.invalid> wrote in message
···················@kolme.ifi.uio.no...
> ···@while.it.lasted.invalid (Asbj�rn Bj�rnst writes:
> BTW. The reason is that locally-enable-sql-reader-syntax is changing
> the reader. Since the reader will read in the whole defun form before
> evaluating it, it is too late to do the call inside the defun. The reader
> has already processed your [*] so changing the syntax will not work.
Of course. Hence the silliness of my WAG.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: Edi Weitz
Subject: Re: Problem enabling bracket mode it CLSQL
Date:
Message-ID: <u1wz1r2fa.fsf@agharta.de>
On 21 Jan 2006 07:58:04 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
> I'm a little unclear on this. If I enable bracket mode in the
> reader, do I need to use CLSQL in object-oriented mode, where my
> tables and rows are classes?
No, the two facilities are orthogonal.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On 21 Jan 2006 07:58:04 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
>
> > I'm a little unclear on this. If I enable bracket mode in the
> > reader, do I need to use CLSQL in object-oriented mode, where my
> > tables and rows are classes?
>
> No, the two facilities are orthogonal.
Hmm. I'm getting errors with the brackets, like [= in a query.
Anything else I need to do besides the call to locally enable the
bracket syntax?
From: Edi Weitz
Subject: Re: Problem enabling bracket mode it CLSQL
Date:
Message-ID: <uwtgtpn4b.fsf@agharta.de>
On 21 Jan 2006 08:11:39 -0800, "Jonathon McKitrick" <···········@bigfoot.com> wrote:
> Hmm. I'm getting errors with the brackets, like [= in a query.
> Anything else I need to do besides the call to locally enable the
> bracket syntax?
Hard to say if you don't post your code. I'd suggest you do that on
the CLSQL mailing list.
My guess is that you think you have enabled the symbolic syntax (what
you call "bracket syntax") but you haven't - it obviously must be
enabled at read time already.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")