compilation pragmas?

compilation pragmas?

[Massimiliano Gubinelli]

Hello,
 I noticed that the Tree IL compiler uses an ad-hoc code to check if some symbol is dynamically defined by GOOPS, intercepting calls to the toplevel-define! function which introduces just a new definition in the current module. In TeXmacs we need some similar dynamics definition mechanism and I get a lot of compiler warnings since the Tree IL analyser does not recognise my definitions. Of course I have the option to redefine  toplevel-define! like GOOPS does, but I’m worried of possible name clashes. Another possibility would be to introduce some “compiler pragma” support in the Tree IL compiler so that it can have annotations which can then be ignored when producing more lower lever code. In this way one could make the mechanism of suppressing particular warnings (e.g. possibly undefined symbols) independent of hacks specific only to certain libraries and provide more orthogonal features. Does it sounds reasonable? I could try to hack it down but I would like to discuss first possible design issues, I’m new to guile compiler.

Best regards,
Massimiliano Gubinelli

Re: compilation pragmas?

[Nala Ginrut]

Hi Massimiliano!
Could you show some code to elaborate on your idea? It's too vague to
understand by a pure text description.

Thanks!

On Wed, May 29, 2019 at 8:43 PM Massimiliano Gubinelli
<m.gubinelli@gmail.com> wrote:
>
> Hello,
>  I noticed that the Tree IL compiler uses an ad-hoc code to check if some symbol is dynamically defined by GOOPS, intercepting calls to the toplevel-define! function which introduces just a new definition in the current module. In TeXmacs we need some similar dynamics definition mechanism and I get a lot of compiler warnings since the Tree IL analyser does not recognise my definitions. Of course I have the option to redefine  toplevel-define! like GOOPS does, but I’m worried of possible name clashes. Another possibility would be to introduce some “compiler pragma” support in the Tree IL compiler so that it can have annotations which can then be ignored when producing more lower lever code. In this way one could make the mechanism of suppressing particular warnings (e.g. possibly undefined symbols) independent of hacks specific only to certain libraries and provide more orthogonal features. Does it sounds reasonable? I could try to hack it down but I would like to discuss first possible design issues, I’m new to guile compiler.
>
> Best regards,
> Massimiliano Gubinelli
>
>

Re: compilation pragmas?

[Massimiliano Gubinelli]

Hi Nala,

> On 29. May 2019, at 18:16, Nala Ginrut <nalaginrut@gmail.com> wrote:
> 
> Hi Massimiliano!
> Could you show some code to elaborate on your idea? It's too vague to
> understand by a pure text description.
> 


Sorry, let me explain by pointing to the code I was referring to:

in module/languages/tree-il/analyze.scm the procedure unbound-variable-analysis
uses the following code to check for dynamic definitions coming from goops:

(define (goops-toplevel-definition proc args env)
  ;; If call of PROC to ARGS is a GOOPS top-level definition, return
  ;; the name of the variable being defined; otherwise return #f.  This
  ;; assumes knowledge of the current implementation of `define-class' et al.
  (define (toplevel-define-arg args)
    (match args
      ((($ <const> _ (and (? symbol?) exp)) _)
       exp)
      (_ #f)))

  (match proc
    (($ <module-ref> _ '(oop goops) 'toplevel-define! #f)
     (toplevel-define-arg args))
    (($ <toplevel-ref> _ 'toplevel-define!)
     ;; This may be the result of expanding one of the GOOPS macros within
     ;; `oop/goops.scm'.
     (and (eq? env (resolve-module '(oop goops)))
          (toplevel-define-arg args)))
    (_ #f)))


I would like a mechanism to remove this hack and allow *any* library to indicate to the tree-il analyser that some symbol has been bound to a variable by some procedure. Seems to me like some compiler pragma since such code could be discarded once the tree-il language has passed the analysis steps and converted to more lower level. Such annotations will not affect code generation but will allow to suppress warnings like “possible unbound symbol”. 

In particular, in TeXmacs we have a custom module system where each module can define global symbols which can be seen by all the other modules and also conditionally overriden under specific situations (e.g. if the user is currently in math mode or not). In order to implement this kind of "contextual overloading” I use code which calls directly module-define! and module-set! to inject new definitions into the global texmacs module. These pieces of code are then not recognised by the tree-il analyser as proper definitions and so I get many warnings which I do not care about…


Irrespective of my specific situation, I find the above code not very nice, since give a special status to the goops library and does not allow the user to specify which procedures have the semantic effect of a symbol definition.

I hope I managed to clarify my intent.

Best
Massimiliano


> Thanks!
> 
> On Wed, May 29, 2019 at 8:43 PM Massimiliano Gubinelli
> <m.gubinelli@gmail.com> wrote:
>> 
>> Hello,
>> I noticed that the Tree IL compiler uses an ad-hoc code to check if some symbol is dynamically defined by GOOPS, intercepting calls to the toplevel-define! function which introduces just a new definition in the current module. In TeXmacs we need some similar dynamics definition mechanism and I get a lot of compiler warnings since the Tree IL analyser does not recognise my definitions. Of course I have the option to redefine  toplevel-define! like GOOPS does, but I’m worried of possible name clashes. Another possibility would be to introduce some “compiler pragma” support in the Tree IL compiler so that it can have annotations which can then be ignored when producing more lower lever code. In this way one could make the mechanism of suppressing particular warnings (e.g. possibly undefined symbols) independent of hacks specific only to certain libraries and provide more orthogonal features. Does it sounds reasonable? I could try to hack it down but I would like to discuss first possible design issues, I’m new to guile compiler.
>> 
>> Best regards,
>> Massimiliano Gubinelli
>> 
>>