(defcc <sn>
-*- := (if (number? -*-)
[-*-]
(error "~A is not a number" -*-)))
(compile <rule> [[1] symbol])
error: [1] is not a number
Isn't -*- supposed to be the head of [1], thus 1? And, consequently:
(compile <rule> [1 symbol])
[1 symbol]
Why does the head of 1 = 1? I would have expected to have an error
message telling me 1 is not a list.
In other words, what I really want is this to parse as valid:
(compile <rule> [[1] symbol])
=== 2 ===
I want something like this to be parsed:
(defcc <foo>
::=;)
(compile <foo> [::=])
fail!
I think this clashes with Qi-YACC's semantic action's reserved symbol
( := ). Therefore, I've tried different strategies but haven't been
successful in accepting ::= as valid syntax. For example, I can accept
the following as valid if I rework a bit my parser:
> I think this clashes with Qi-YACC's semantic action's reserved symbol
> ( := ). Therefore, I've tried different strategies but haven't been
> successful in accepting ::= as valid syntax. For example, I can accept
> the following as valid if I rework a bit my parser:
> but I can't use this parser to parse what I really want:
> (compile <foo> [::=])
> fail!
> And I can't define my parser as follows:
> (defcc <foo>
> #\:#\:#\=;)
> READ from #<INPUT STRING-INPUT-STREAM>: there is no character with
> name ":#"
> In languages with which I'm more familiar, it's possible to read
> character literals without any whitespace between each one; but not in
> Qi, AFAIK.
Thanks for the answer to my question 1. Have you seen my question 2?
=== 1 ===
So you're telling me that <rule> doesn't send the head of the stuff to
be parsed to <sn>, and the rest of it to <sym>?
(defcc <rule>
<sn> <sym>;)
I thought that the space between <sn> and <sym> in <rule> told the
compiler to try to parse the first element using <sn>, and the rest of
the elements using <sym>. But maybe I assumed too much in thinking the
compiler knows how to take the head of something this way.
So if I understand well now, it's not the head that's sent to <sn> but
the whole, because <rule> doesn't know what <sn> really wants. And
once <sn> has done taking out whatever it wanted, <rule> will send the
rest to <sym>. Is that a proper way to think about it?
I think I'll reread chapter 8 (metaprograms); I might have read it too
fast last week.
On Sep 9, 8:42 am, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > I think this clashes with Qi-YACC's semantic action's reserved symbol
> > ( := ). Therefore, I've tried different strategies but haven't been
> > successful in accepting ::= as valid syntax. For example, I can accept
> > the following as valid if I rework a bit my parser:
> > but I can't use this parser to parse what I really want:
> > (compile <foo> [::=])
> > fail!
> > And I can't define my parser as follows:
> > (defcc <foo>
> > #\:#\:#\=;)
> > READ from #<INPUT STRING-INPUT-STREAM>: there is no character with
> > name ":#"
> > In languages with which I'm more familiar, it's possible to read
> > character literals without any whitespace between each one; but not in
> > Qi, AFAIK.
> So if I understand well now, it's not the head that's sent to <sn> but
> the whole, because <rule> doesn't know what <sn> really wants. And
> once <sn> has done taking out whatever it wanted, <rule> will send the
> rest to <sym>. Is that a proper way to think about it?
> > So if I understand well now, it's not the head that's sent to <sn> but
> > the whole, because <rule> doesn't know what <sn> really wants. And
> > once <sn> has done taking out whatever it wanted, <rule> will send the
> > rest to <sym>. Is that a proper way to think about it?
> I think this clashes with Qi-YACC's semantic action's reserved symbol
> ":=".
> I've tried different strategies but haven't been successful in
> accepting ::= as valid (see the start of this thread for my trials).
> What should I do?
> On Sep 9, 12:59 pm, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > > So if I understand well now, it's not the head that's sent to <sn> but
> > > the whole, because <rule> doesn't know what <sn> really wants. And
> > > once <sn> has done taking out whatever it wanted, <rule> will send the
> > > rest to <sym>. Is that a proper way to think about it?
> > I think this clashes with Qi-YACC's semantic action's reserved symbol
> > ":=".
> > I've tried different strategies but haven't been successful in
> > accepting ::= as valid (see the start of this thread for my trials).
> > What should I do?
> > On Sep 9, 12:59 pm, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > > > So if I understand well now, it's not the head that's sent to <sn> but
> > > > the whole, because <rule> doesn't know what <sn> really wants. And
> > > > once <sn> has done taking out whatever it wanted, <rule> will send the
> > > > rest to <sym>. Is that a proper way to think about it?
Thinking of it, I don't even need ::= to be parsed as ::=. My real
intention is to translate stuff. But I'm still confounded by this side-
effect of something I'm not aware of.
From this below, I see that a colon (:) seems to somehow quote what
follows. But I'm really not sure about this. I suppose I'll have to
hope to find my answer in the reader's source code?
That said, I'd like to know the difference between:
- :... <--
- |...| <--
- #\... <-- character
- Qi::Bar (or approximately)
(8-) :=
:=
(9-) ::=
:=
(10-) :::=
READ from #<INPUT STRING-INPUT-STREAM>: too many colons in token
":::="
(10-) :1
:|1|
(11-) ::1
:|1|
(12-) :::1
READ from #<INPUT STRING-INPUT-STREAM>: too many colons in token ":::
1"
(12-) :a
:a
(13-) ::a
:a
(14-) :::a
READ from #<INPUT STRING-INPUT-STREAM>: too many colons in token
":::a"
(16-) (= := =)
false
(17-) (= := ::=)
true
On Sep 9, 7:16 pm, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > > I think this clashes with Qi-YACC's semantic action's reserved symbol
> > > ":=".
> > > I've tried different strategies but haven't been successful in
> > > accepting ::= as valid (see the start of this thread for my trials).
> > > What should I do?
> > > On Sep 9, 12:59 pm, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > > > > So if I understand well now, it's not the head that's sent to <sn> but
> > > > > the whole, because <rule> doesn't know what <sn> really wants. And
> > > > > once <sn> has done taking out whatever it wanted, <rule> will send the
> > > > > rest to <sym>. Is that a proper way to think about it?
You should now that the symbols in qi follows the rules of comon-lisp
:alpha represents a key symbol
::alpha is the same
:::alpha The underlying CL engine cannot interpret this, the reson is
that
:: is a namespace operator e.g. qi::ebr calls the ebr function in the
qi package.
You need to work at the character stream level and or work with
strings
/Stefan
On 10 Sep, 02:39, Daniel Jomphe <danieljom...@gmail.com> wrote:
> Thinking of it, I don't even need ::= to be parsed as ::=. My real
> intention is to translate stuff. But I'm still confounded by this side-
> effect of something I'm not aware of.
> From this below, I see that a colon (:) seems to somehow quote what
> follows. But I'm really not sure about this. I suppose I'll have to
> hope to find my answer in the reader's source code?
> That said, I'd like to know the difference between:
> - :... <--
> - |...| <--
> - #\... <-- character
> - Qi::Bar (or approximately)
> (8-) :=
> :=
> (9-) ::=
> :=
> (10-) :::=
> READ from #<INPUT STRING-INPUT-STREAM>: too many colons in token
> ":::="
> (10-) :1
> :|1|
> (11-) ::1
> :|1|
> (12-) :::1
> READ from #<INPUT STRING-INPUT-STREAM>: too many colons in token ":::
> 1"
> (12-) :a
> :a
> (13-) ::a
> :a
> (14-) :::a
> READ from #<INPUT STRING-INPUT-STREAM>: too many colons in token
> ":::a"
> (16-) (= := =)
> false
> (17-) (= := ::=)
> true
> On Sep 9, 7:16 pm, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > Type ::= to top level and reflect.
> > On 9 Sep, 22:21, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > > Since := is part of Qi-yacc syntax; push it into the semantics.
> > > > I think this clashes with Qi-YACC's semantic action's reserved symbol
> > > > ":=".
> > > > I've tried different strategies but haven't been successful in
> > > > accepting ::= as valid (see the start of this thread for my trials).
> > > > What should I do?
> > > > On Sep 9, 12:59 pm, Mark Tarver <dr.mtar...@ukonline.co.uk> wrote:
> > > > > > So if I understand well now, it's not the head that's sent to <sn> but
> > > > > > the whole, because <rule> doesn't know what <sn> really wants. And
> > > > > > once <sn> has done taking out whatever it wanted, <rule> will send the
> > > > > > rest to <sym>. Is that a proper way to think about it?
|
