From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Massimiliano Gubinelli Newsgroups: gmane.lisp.guile.devel Subject: Re: compilation pragmas? Date: Wed, 29 May 2019 23:56:54 +0200 Message-ID: References: <1B2ADD73-2026-4707-A0AF-EB6A7EA7297C@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="113005"; mail-complaints-to="usenet@blaine.gmane.org" Cc: guile-devel To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 29 23:57:12 2019 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hW6ZM-000TIy-3p for guile-devel@m.gmane.org; Wed, 29 May 2019 23:57:12 +0200 Original-Received: from localhost ([127.0.0.1]:59934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hW6ZK-0001cj-Vo for guile-devel@m.gmane.org; Wed, 29 May 2019 17:57:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:45638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hW6ZB-0001cS-UH for guile-devel@gnu.org; Wed, 29 May 2019 17:57:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hW6ZA-0000JR-O1 for guile-devel@gnu.org; Wed, 29 May 2019 17:57:01 -0400 Original-Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:34968) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hW6ZA-0000Is-HF for guile-devel@gnu.org; Wed, 29 May 2019 17:57:00 -0400 Original-Received: by mail-wm1-x330.google.com with SMTP id w9so2539286wmi.0 for ; Wed, 29 May 2019 14:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YdNdH2M9XacaOmXiOLID0esGOn2WWlk6hpbE0R57mVo=; b=COZCrY/zhtz2/BOcroP1IPUuCsMGbS5l1TyUeJcqfT6IuDPqi+OkSqHP7QLvdVmTUR hRXyw1wl9obYjvke+mNrA4Riy3oYzWhJCIs3/eik5lRcaloZA9D/LCAeXykyE76pLXZj Z1hsmKcEDqeIk/5m9YZWAQLlkQ8PiVokyIoKqCW4PqBH0A3xVDC9jig16axwK5IBJiVB 9pYHYPVm5J+Ux3mInUUdAF45YQxsTZI80tTWgH9obxpnvJOSKdEQXVKqCm9GKKlwA06q 6tAG0JZRLjpw6rvcMgqLLY32ZKhb6nt1n7nKRr105xzY/M2Q4Oq9oAxbOA3nWQxiLXXb Xv6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YdNdH2M9XacaOmXiOLID0esGOn2WWlk6hpbE0R57mVo=; b=MmGl+SsP+aVwB0kVXwrTKHOPslCi1qBAAVMyHgnNI6jqvJ1cheiYSkP21D4Tkhms7T FO9xjCG3k9jP9+kzx9c/0xl3lLAq7ySU+bpMlf9MOfJ8PZ/qGe2QYv02P8FCU0ALZnZC 0jk4OeAcDZlpNR08lMs5P+yPipjBiL2GYn2nKCkCN93ptDX9qem9zQxungrdaBDqbmk+ caOfRMVV0SJoSjuT3bw54SZ2PYh9B2eMv5tuPxdfzVmFL1pVsNz8mkUrqy/LzFPjtSll YMPbXfaL+NnqOpr1WU6o+/PGDTHJy9KelPlEz9MF9x6VTVL2mtjaRtAeX7s2zCrSztbP IJtA== X-Gm-Message-State: APjAAAUeP9pZ1YPv8TIHQEvVNgksWCKr0FJH3mNrzcsJgeId5V1wRCNI PHPIU464eMVVZDeBIkUpaU8= X-Google-Smtp-Source: APXvYqzIta0/d3mDsdP4jDN5Lqt04c6gweXtGSflDhdb8V0kldYqo3jvoxPiMWK/INE3KNQZ4xatJQ== X-Received: by 2002:a05:600c:23cf:: with SMTP id p15mr144372wmb.31.1559167018403; Wed, 29 May 2019 14:56:58 -0700 (PDT) Original-Received: from ?IPv6:2001:4dd6:e2d2::12f:578c:b06:3e52? (2001-4dd6-e2d2-0-12f-578c-b06-3e52.ipv6dyn.netcologne.de. [2001:4dd6:e2d2:0:12f:578c:b06:3e52]) by smtp.gmail.com with ESMTPSA id z74sm8054381wmc.2.2019.05.29.14.56.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 14:56:57 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3445.104.8) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::330 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19935 Archived-At: Hi Nala, > On 29. May 2019, at 18:16, Nala Ginrut wrote: >=20 > Hi Massimiliano! > Could you show some code to elaborate on your idea? It's too vague to > understand by a pure text description. >=20 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 ((($ _ (and (? symbol?) exp)) _) exp) (_ #f))) (match proc (($ _ '(oop goops) 'toplevel-define! #f) (toplevel-define-arg args)) (($ _ '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 = =E2=80=9Cpossible unbound symbol=E2=80=9D.=20 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=E2=80=9D 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=E2=80=A6 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! >=20 > On Wed, May 29, 2019 at 8:43 PM Massimiliano Gubinelli > wrote: >>=20 >> 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=E2=80=99m worried = of possible name clashes. Another possibility would be to introduce some = =E2=80=9Ccompiler pragma=E2=80=9D 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=E2=80=99m= new to guile compiler. >>=20 >> Best regards, >> Massimiliano Gubinelli >>=20 >>=20