Hi Lispers,
I have a following problem :
I have some graph pattern which is used to describe which structure in
search graph should be found. This pattern can look like this :
(defparameter *pattern-1*
'((0 :5 ((3) (1)))
(1 :3 ((3) (1 -)))
(2 :0)
(3 + atom-node ((4) (5) (6 -)))
(4 atom-node ((4) (5)))
(5 variable-node ((2) (7 -)))
(6 - cost-node ((0) (7)))
(7 - cost-node ((4) (7)))))
Then, I have a function, which generates a lambda function which finds
such pattern in search graph. For example, for the pattern above such
function looks like this :
SCSP> (genmatch *pattern-1*)
(LAMBDA (SEARCH-GRAPH PATTERN->SEARCH-MAPPING)
(WHEN (>= (NODES-COUNT-OF SEARCH-GRAPH) 6)
(LET ((RESULT-MAPPING (MAKE-RESULT-ARRAY 8 3
PATTERN->SEARCH-MAPPING))
(ALL-MAPPINGS 'NIL)
(LAST-MATCH-SUCCESSFULL NIL)
(SEARCH-GRAPH-EDGE NIL))
(WHEN
(AND
(OR
(NULL (SETF SEARCH-GRAPH-EDGE (GET-OUT-EDGE SEARCH-GRAPH
(AREF RESULT-MAPPING 1) (AREF RESULT-MAPPING 1))))
(NOT (FUNCALL # #<RELATION-EDGE {ACCFCC9}> (EDGE-ATTRIBUTE
SEARCH-GRAPH-EDGE))))
(AND (SETF SEARCH-GRAPH-EDGE (GET-OUT-EDGE SEARCH-GRAPH
(AREF RESULT-MAPPING 0) (AREF RESULT-MAPPING 1)))
(FUNCALL # #<RELATION-EDGE {ACCF711}> (EDGE-ATTRIBUTE
SEARCH-GRAPH-EDGE))))
(REMATCH (FUNCALL # SEARCH-GRAPH RESULT-MAPPING)
:FOUND-CALLBACK
(LAMBDA (STATE)
(DUMP-STATE! STATE RESULT-MAPPING 3 1)
(REMATCH (FUNCALL # SEARCH-GRAPH RESULT-MAPPING)
:FOUND-CALLBACK
(LAMBDA (STATE)
(DUMP-STATE! STATE RESULT-MAPPING 4 2)
(WHEN
(AND
(SETF SEARCH-GRAPH-EDGE
(GET-OUT-EDGE SEARCH-GRAPH
(AREF RESULT-MAPPING 4) (AREF RESULT-MAPPING 4)))
(FUNCALL # #<RELATION-EDGE
{ACD08C1}> (EDGE-ATTRIBUTE SEARCH-GRAPH-EDGE)))
(REMATCH (FUNCALL # SEARCH-GRAPH
RESULT-MAPPING)
:FOUND-CALLBACK
(LAMBDA (STATE)
(DUMP-STATE! STATE
RESULT-MAPPING 6 2)
(UNLESS
(AND
(SETF SEARCH-GRAPH-EDGE
(GET-OUT-EDGE
SEARCH-GRAPH
(AREF RESULT-MAPPING 7)
(AREF RESULT-MAPPING 7)))
(FUNCALL #
#<RELATION-EDGE {ACD0A21}>
(EDGE-ATTRIBUTE SEARCH-GRAPH-EDGE)))
(SETF
LAST-MATCH-SUCCESSFULL
T
ALL-MAPPINGS
(CONS
RESULT-MAPPING ALL-MAPPINGS)))
(IF LAST-MATCH-SUCCESSFULL
T
(PROGN
(CLEAR-RESULT-ARRAY! RESULT-MAPPING 6 2) NIL)))))
(PROGN
(IF LAST-MATCH-SUCCESSFULL
(SETF RESULT-MAPPING
(MAKE-RESULT-ARRAY 8 4
RESULT-MAPPING)
LAST-MATCH-SUCCESSFULL
NIL)
(CLEAR-RESULT-ARRAY! RESULT-MAPPING
4 2))
NIL)))
(IF (NOT (NULL ALL-MAPPINGS)) T (PROGN
(CLEAR-RESULT-ARRAY! RESULT-MAPPING 3 1) NIL)))))
ALL-MAPPINGS)))
Now, I want to compile the result lambda, and use it, and here comes
the wrapper macro :
(defmacro defmatch (pattern-desc &key
(n-cmp (lambda (x y) (declare (ignore x y)) t))
(e-cmp (lambda (x y) (declare (ignore x y)) t)))
(genmatch pattern-desc :node-comparator n-cmp :edge-comparator
e-cmp))
It works ok this way :
SCSP> (funcall (defmatch ((0 :0 ((0 -) (1)))
(1 + atom-node)
(2 atom-node)))
*s* #(4))
(#(4 0 6) #(4 0 5) #(4 0 3) #(4 0 2) #(4 0 1))
when I supply the pattern itself directly to the macro.
My big problem is, that I can't use this macro to generate code for
some pattern which is stored in variable. When I want to use
*pattern-1* :
SCSP> (defmatch *pattern-1*)
The value *PATTERN-1* is not of type SEQUENCE.
[Condition of type TYPE-ERROR]
Restarts:
0: [ABORT-REQUEST] Abort handling SLIME request.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
{ABBAA51}>)
Backtrace:
0: (LENGTH *PATTERN-1*)
1: (VALIDATE-PATTERN *PATTERN-1*)
2: (CREATE-PATTERN *PATTERN-1*)
3: (GENMATCH *PATTERN-1* :NODE-COMPARATOR #<FUNCTION (LAMBDA (X Y))
{A6AAC05}> :EDGE-COMPARATOR #<FUNCTION (LAMBDA (X Y)) {A6AAC3D}>)
4: (MACROEXPAND-1 (DEFMATCH *PATTERN-1*) #<NULL-LEXENV>)
5: (MACROEXPAND (DEFMATCH *PATTERN-1*) #<NULL-LEXENV>)
6: (SB-INT:EVAL-IN-LEXENV (DEFMATCH *PATTERN-1*) #<NULL-LEXENV>)
7: (SWANK::EVAL-REGION "(defmatch *pattern-1*)
The problem is, that macro passes the variable name, and not the value
of the variable I think, but I don't know what to do to have
possibility to directly include either patter itself or variable which
contains the pattern.
Any ideas?
Thank you,
Karol
"Karol Skocik" <············@gmail.com> writes:
> My big problem is, that I can't use this macro to generate code for
> some pattern which is stored in variable. When I want to use
> *pattern-1* :
>
> SCSP> (defmatch *pattern-1*)
Right, that's not what macros are for. I could give you longish
explanation of why but it wouldn't likely be as good as the one I
already wrote here:
<http://www.gigamonkeys.com/book/macros-defining-your-own.html>
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Ok, I think I understand and it is not possible. At compile time,
normal variables are inaccessible, right?
Karol
Peter Seibel wrote:
> "Karol Skocik" <············@gmail.com> writes:
>
> > My big problem is, that I can't use this macro to generate code for
> > some pattern which is stored in variable. When I want to use
> > *pattern-1* :
> >
> > SCSP> (defmatch *pattern-1*)
>
> Right, that's not what macros are for. I could give you longish
> explanation of why but it wouldn't likely be as good as the one I
> already wrote here:
>
> <http://www.gigamonkeys.com/book/macros-defining-your-own.html>
>
> -Peter
>
> --
> Peter Seibel * ·····@gigamonkeys.com
> Gigamonkeys Consulting * http://www.gigamonkeys.com/
> Practical Common Lisp * http://www.gigamonkeys.com/book/
"Karol Skocik" <············@gmail.com> writes:
> Ok, I think I understand and it is not possible. At compile time,
> normal variables are inaccessible, right?
Correct. But that's fine because in cases like this you can just write
a function that takes runtime data and does what you want, possibly
using COMPILE to compile an anonymous LAMBDA expression if you're
going to call it a bunch of times.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
"Karol Skocik" <············@gmail.com> writes:
> Hi Lispers,
> I have a following problem :
>
> I have some graph pattern which is used to describe which structure in
> search graph should be found. This pattern can look like this :
> [...]
> The problem is, that macro passes the variable name, and not the value
> of the variable I think, but I don't know what to do to have
> possibility to directly include either patter itself or variable which
> contains the pattern.
>
> Any ideas?
You didn't read the newsgroup this week did you?
http://groups.google.com/group/comp.lang.lisp/tree/browse_frm/thread/ffabc446adf77471/2f0d7ca110409bcd?rnum=1&hl=en&q=group%3Acomp.lang.lisp+author%3APascal+author%3ABourguignon&_done=%2Fgroup%2Fcomp.lang.lisp%2Fbrowse_frm%2Fthread%2Fffabc446adf77471%2F0ef88943a891fe09%3Flnk%3Dst%26q%3Dgroup%3Acomp.lang.lisp+author%3APascal+author%3ABourguignon%26rnum%3D11%26hl%3Den%26#doc_aced98a13ca36b45
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
I read regularly but I missed this one ;)
Thank you both!
Karol
Pascal Bourguignon wrote:
> "Karol Skocik" <············@gmail.com> writes:
>
> > Hi Lispers,
> > I have a following problem :
> >
> > I have some graph pattern which is used to describe which structure in
> > search graph should be found. This pattern can look like this :
> > [...]
> > The problem is, that macro passes the variable name, and not the value
> > of the variable I think, but I don't know what to do to have
> > possibility to directly include either patter itself or variable which
> > contains the pattern.
> >
> > Any ideas?
>
> You didn't read the newsgroup this week did you?
>
> http://groups.google.com/group/comp.lang.lisp/tree/browse_frm/thread/ffabc446adf77471/2f0d7ca110409bcd?rnum=1&hl=en&q=group%3Acomp.lang.lisp+author%3APascal+author%3ABourguignon&_done=%2Fgroup%2Fcomp.lang.lisp%2Fbrowse_frm%2Fthread%2Fffabc446adf77471%2F0ef88943a891fe09%3Flnk%3Dst%26q%3Dgroup%3Acomp.lang.lisp+author%3APascal+author%3ABourguignon%26rnum%3D11%26hl%3Den%26#doc_aced98a13ca36b45
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> READ THIS BEFORE OPENING PACKAGE: According to certain suggested
> versions of the Grand Unified Theory, the primary particles
> constituting this product may decay to nothingness within the next
> four hundred million years.