about the necessity of 'list it is because optimizer-parse-square-brackets-arguments-lister return a list like this: ((- 6 4) : (+ i 2)) BUT i suspect ,as in scheme , a bit due to homoiconicity of lisp/scheme (that represent code and data the same way) that out of context ((- 6 4) : (+ i 2)) can be evaluated and interpreted as (2 : (+ i 2)) depending of i and then interpreted as (apply 2 (: (+ i 1)) but that is not what i want here and optimizer-parse-square-brackets-arguments-lister was first used in procedure , not pre-compil macro before expansion.
about #f , i'm working symbolically, at this stage for optimisation, the context ,and bindings will be evaluated when the expansion of macro is done and then evaluated . Keep in mind ,all that is for testing, beta-code ,and i'm discovering new things about macro, and that my knowledge and the code could change again. If someone have concrete solution to write better code i will be glad to integrate this in my code. On Mon, May 6, 2024 at 12:29 PM Damien Mattei <damien.mat...@gmail.com> wrote: > at any point in any scheme if the user write such a thing: > (let ((list 3)) (list 4)) > there will be a serious problem > > On Mon, May 6, 2024 at 11:41 AM Jean Abou Samra <j...@abou-samra.fr> > wrote: > >> > (with-syntax ((parsed-evaluated-args >> > (datum->syntax #f (cons 'list >> (optimizer-parse-square-brackets-arguments-lister >> > (syntax->datum >> #'args-brackets)))))) >> >> That should work, but it's also non-hygienic. For example, it will >> be affected if the user does >> >> (let ((list ...)) >> (call-your-macro ...)) >> >> and since you use #f in the datum->syntax call, it will also strip away >> all hygiene annotations from the args-brackets, causing problems inside >> that as well. >> >> I'd advise you refactor your >> optimizer-parse-square-brackets-arguments-lister >> function so that it takes #'args-brackets instead of (syntax->datum >> #'args-brackets) >> and works with it in a hygienic way. >> >
