Re: Module reflection and the list of bound symbols

[Ian Price]

Panicz Maciej Godek  writes:

> On the other hand, there is no way (or I haven't found one)
> to list the bound symbols explicitly. It seems tempting to
> have a reflection function `module-symbols' or `environment-symbols'
> that would return the names of bound symbols,
> or to have functions like environment->list or module->list that
> would return assoc lists mapping symbols to their values.
Hmm, no, but you are able to get the "obarray" for the module which is a
hash of symbols -> variables.

(define (hash-keys hash)
  (hash-fold (lambda (key val prev)
   (cons key prev))
 '()
 hash))

(define (module-exports module)
  (hash-keys (module-obarray module)))

scheme@(guile−user)> (module-exports (resolve-module '(pfds queues)))
$20 = (queue−>list queue−empty−condition? enqueue &queue−empty
queue−length make−queue rotate queue−l∧ dummy queue−l
make−queue−empty−condition %module−public−interface list−>queue
dequeue queue−empty? queue? queue %make−queue queue−r makeq)

This lists _all_ the bindings, even the non-public ones.

I'm sure there is a way to get only the public (exported) ones using the
interfaces, but that is beyond my knowledge at the moment.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Module reflection and the list of bound symbols

[David Pirotte]

Hello,

> ... to get only the public (exported) ones using the
> interfaces, but that is beyond my knowledge at the moment.

Here is what i do, see the attached code [which i copied from
guile-gnome], then you can use it this way, as an example:

1. you define a module b and export some ...

2.

   ;;; file a.scm STARTS here
   (define-module (a)
 :use-module (reexport)  
 :use-module (b))
 :export ... ...

   (eval-when (compile load eval)
 (re-export-public-interface (b)))

   ;; your code here...
   ;; ...
   ;;; file a.scm ENDS here

3.

   finally:

   guile
   scheme@(guile-user)> (use-modules (a))
   ;; then you can use both public interface from a and b
  

Of course this is true for any module which uses the module a [it can
refers to the public interface of b too...]

Hope this helps,
Cheers,
David

ps: i have always tought guile itself should provide this feature as 
built-in
;; -*- mode: scheme; coding: utf-8 -*-

 Copyright (C) 2011, 2012
 Free Software Foundation, Inc.

 This library is free software: you can redistribute it and/or
 modify it under the terms of the GNU General Public License as
 published by the Free Software Foundation, either version 3 of
 the License, or (at your option) any later version.

 This library is distributed in the hope that it will be useful, but
 WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 General Public License for more details.

 You should have received a copy of the GNU General Public License
 along with this library.  If not, see .


;;; Commentary:

;; this code is the same as the one use by guile-gnome, see
;; /usr/local/share/guile-gnome-2/gnome/gw/support/modules.scm

;;; Code:

(define-module (macros reexport)
  :export (re-export-public-interface))


(define-macro (re-export-public-interface . args)
  "Re-export the public interface of a module or modules. Invoked as
@code{(re-export-modules (mod1) (mod2)...)}."
  (if (null? args)
  '(if #f #f)
  `(begin
	 ,@(map (lambda (mod)
		  (or (list? mod)
		  (error "Invalid module specification" mod))
		  `(module-use! (module-public-interface (current-module))
(resolve-interface ',mod)))
		args

Re: procedure-source availability

[Panicz Maciej Godek]

I've found a bug report on savannah, which noted the lack of
``procedure-source'' for guile 1.9.11
http://savannah.gnu.org/bugs/?30469
I wonder if any further decisions were made regarding the maintenance
of ``procedure-source''. I would find it really useful for my
application if the sexp containing the lambda expression that was used
to generate the procedure was stored in it's property list, and I
don't understand why this isn't currently done. (Is it because of the
performance issues?)
Best regards
MG

Re: procedure-source availability

[Mark H Weaver]

On 09/30/2012 04:11 PM, Panicz Maciej Godek wrote:

I've found a bug report on savannah, which noted the lack of
``procedure-source'' for guile 1.9.11
http://savannah.gnu.org/bugs/?30469
I wonder if any further decisions were made regarding the maintenance
of ``procedure-source''. I would find it really useful for my
application if the sexp containing the lambda expression that was used
to generate the procedure was stored in it's property list, and I
don't understand why this isn't currently done.


Out of curiosity, why do you need this?

The reason I ask is that, in the presence of macros, it is not clear 
what you mean by the "procedure-source".


Do you mean before macro expansion?  If so, what use it is to you, since 
it may contain user macros that your code cannot understand? 
Furthermore, many procedures simply don't exist before macro expansion. 
 For example, a record type definition expands to several procedure 
definitions that do not exist in the original source.


If you mean after macro expansion (or perhaps in some intermediate state 
of macro expansion, e.g. at the point where the macro expander first 
encounters the lambda expression), then a normal sexp with the original 
identifier names is no longer sufficient.  In psyntax, these 
intermediate forms are represented as syntax objects, but at the very 
least you'd need to rename the identifiers to prevent unintended 
variable capture.


It's a very thorny issue, and I suspect that's the reason that 
'procedure-source' no longer works.  If we are going to reimplement that 
functionality, then we first need to figure out precisely what it 
_should_ do in the general case.  Which brings me back to the question: 
"Why do you need this?"


Regards,
  Mark