[<<][staapl][>>][..]
Tue Oct 2 14:38:47 CEST 2007

type signatures from pattern matching macros

It should be possible to mine the 'source' field of pattern matching
macros for types, or at leas stack effect, of functions.

the first matching rule is always the most specific one: if that fits
a certain pattern.

the REAL solution here is to change the pattern matcher to REAL
algebraic types instead of this hodge-podge. moral of the story:
whenever pattern matching occurs on list structure, what you really
are looking for is algebraic types.

yes... i'm not going to muck around in this ad-hoc syntax. i need a
real solution: something on top of the current tx. i need real
algebraic types.

there is this:
http://planet.plt-scheme.org/package-source/dherman/struct.plt/2/3/doc.txt

but for my purpose it might be better to just stick with the current
concrete list representation for the asm buffer.

what about:


(([qw a] [qw b] +)   ([qw (+ a b)]))

->

((['qw a] ['qw b] +)   `([qw ,(+ a b)]))


looks like 'atyped->clause' in pattern-tx.ss is working. it's indeed
really simple to implement on top of the matching clauses.

looks like 'asm-transforms' works too.

i ran into one difficulty though. call it polymorphism. in original syntax:

   (([op 'POSTDEC0 0 0] ['save] opti-save) `([,op INDF0 1 0]))

cannot be expressed in the new syntax. however, this is
exceptional. it's probably a good idea to make this polymorphism
explicit. EDIT: it is possible to use unquote!! a bit of abuse of
notation, but ...

let's write the pic18 preprocessor on top of asm-transforms instead of
compiler-patterns.

ok. done. old one's gone.

now it should be a lot easier to write some documentation or type
inference..

i tried to tackle the 'pic18-meta-patterns' but i don't seem to get
anywhere. current syntax is way to complicated. it really shouldn't be
too hard by taking a more bottom up approach instead of trying to use
'callbacks' that force the preprocessing of some macro's
arguments. write a single generator macro for each kind.

trying again. this is the thing i want to generate:

  (define-syntax unary
    (syntax-rules ()
      ((_ namespace (word opcode ...))
       (asm-transforms namespace
                       (([movf f 0 0] word) ([opcode f 0 0])) ...
                       ((word)              ([opcode 'WREG 0 0])) ...))))

from this

  (asm-meta-pattern (unary (word opcode))
    (([movf f 0 0] word) ([opcode f 0 0]))
    ((word)              ([opcode 'WREG 0 0])))


the thing which seems problematic to me is the '...'

more specificly

(pattern template) ...   ->   (pattern template) (... ...) ...

that doesn't seem to work.

it looks like the 'real' problem here is due to the fact that i'm
expanding to something linear.. i'm inserting stuff. i wonder if it's
possible to modify the asm syntax a bit so it will flatten
expressions.

wooo.. macros like this are difficult. i'm currently doing something
wrong with mixing syntax-rules with calling an expander directly. best
to stick with plain syntax-case and direct expansion: that's easier to
get right.

the deal was: sticking with syntax-rules as a result of a first
expansion worked fine, i just needed to put the higher order macro in
a different file for phase separation reasons.

so.. the remaining step is to collapse the compiler-patterns-stx
phase, and add the current source patterns to the word source field,
which would yield decent docs.

ok, done.

> msee +
asm-match:
((((qw a) (qw b) +) ((qw `(,@(wrap a) ,@(wrap b) +))))
 (((qw a) +) ((addlw a)))
 (((save) (movf a 0 0) +) ((addwf a 0 0)))
 ((+) ((addwf 'POSTDEC0 0 0))))
>

that should be easy enough to parse :)
CAR + look only at qw.

the 'wrap' thing is something that needs to be cleaned up too.. i
tried but started breaking things. enough for today.

this is what i get out for qw -> qw

(((qw a) (qw b) --) ((qw `(,@(wrap a) ,@(wrap b) #f))))
(((qw a) (qw b) >>>) ((qw `(,@(wrap a) ,@(wrap b) >>>))))
(((qw a) (qw b) <<<) ((qw `(,@(wrap a) ,@(wrap b) <<<))))
(((qw a) drop) ())
(((qw thing) |*'|) ((qw thing)))
(((qw a) (qw b) ++) ((qw `(,@(wrap a) ,@(wrap b) #f))))
(((qw a) (qw b) swap) ((qw b) (qw a)))
(((qw a) dup) ((qw a) (qw a)))
(((qw a) (qw b) or) ((qw `(,@(wrap a) ,@(wrap b) or))))
(((qw a) (qw b) and) ((qw `(,@(wrap a) ,@(wrap b) and))))
(((qw a) neg) ((qw `(,@(wrap a) -1 *))))
(((qw a) (qw b) xor) ((qw `(,@(wrap a) ,@(wrap b) xor))))
(((qw a) (qw b) /) ((qw `(,@(wrap a) ,@(wrap b) /))))
(((qw a) (qw b) *) ((qw `(,@(wrap a) ,@(wrap b) *))))
(((qw a) (qw b) -) ((qw `(,@(wrap a) ,@(wrap b) -))))
(((qw a) (qw b) +) ((qw `(,@(wrap a) ,@(wrap b) +))))

i also made a 'print-type' function. for '+' :

((qw qw) => (qw))
((qw) => (addlw))
((save movf) => (addwf))
(() => (addwf))

this might be useful.. but what's more useful is the building of a
framework that enables this for all functions. it works for the
assembler primitives only.



[Reply][About]
[<<][staapl][>>][..]