[Bese-devel] custom yaclml and deftag-macro

[Evrim ULU]

Attila Lendvai wrote:

>> Ok this works. I have a request since the current situation breaks
>> older macros.  it's very time consuming to fix old codes as you know.
>>
>> It would be better if we can have something like:
>>
>> (deftag-macro x (&attribute xyz &allow-other-attributes others
>> &allow-custom-attributes custom)
>>  `(<:input (@ , at custom) :name ,xyz ,others))
>
>
pasting from attribute-bind:

          ,(when body-var
              `(setf ,body-var ,attribute-values))
;;            ,(when other-attributes
;;               `(setf ,other-attributes (append (nreverse
,other-attributes) ,custom-attributes)))
           ,@(if (and (consp body)
                      (consp (car body))

Commenting above lines did what i want. I only need to do nreverse over
other-attributes. The evalutation problem may be solved by making (list
, at custom) so that the inside variables of the custom is evaluated before
going into tags.

> that should be , at others, but read below.
>
> we have a choice here:
>
> - currently OTHERS also contain the CUSTOM attributes when
> &allow-other-attributes is given. this simplifies using
> &allow-other-attributes, but it also means that "SomE" non-keyword
> attribute names can appear in the OTHERS list, so you can't simply
> , at OTHERS, but have to (@ , at OTHERS) to propagate the attributes to the
> inner tag.
>
> - this could be dropped and OTHERS/CUSTOMS separated and then , at OTHERS
> were safe for the simple , at OTHERS, but then you would have to deal
> with &allow-custom-attributes separately with an additional (@
> , at CUSTOMS)  if you want to allow custom attributes. imho this is
> cumbersome most of the time. i think most of the time you just want to
> specify that you allow other attributes to disable the warnings, and
> you don't care if they will be specified as keyword attrs or custom
> attrs.
>
> that's why i've decided for the former which is implemented currently.
> but i think it's compatible with the old code as long as you don't use
> custom attributes but they didn't exist before so i think it should be
> backwards compatible.


My inner feelings tell me that if others imply custom, macros using
macros would fail since other attributes are passed directly as custom
attributes. So keeping them seperate would bless us and keep us away
from these kinds of bugs.

Breaking the backward compatilbity would lead confusion among users.
This is more important i think.

>> I'm happy with the @ sign btw, why did you think to change it to *?
>
>
> you missed an important detail, before the patch
>
> (let ((x '("foo" 42))
>  (<:bar (@ x) :some "other"))
>
> was taking the attribute list found in X _at runtime_, which i think
> is different enough to deserve a different notation. i've proposed (*
> x var2 ...) for that.
>
Hm does that mean a second sign to use like (* '(foo 42))? If it is,
that's ok with me.

Comments on the overall situation:

The attribute-bind macro is bloated. I really don't like the hash table
approach (*expander-..*), if i have time i want to change deftag and
deftag-macros to generate real macro to parse attributes so that we get
rid of attribute-bind. It would be more efficient and easy to debug.

I admit i can't debug it now, 4+ levels of macro expanding is beyond my
and users imagination.

Comments?

Thanks.
evrim.