Gambit-modules-list Mars 2009

gambit-modules-list@iro.umontreal.ca

7 participants
8 discussions

Syntactic tower
by Per Eckerdal 02 Avr '09

02 Avr '09

Hello again. I have been thinking about how to implement the syntactic tower in a simple but correct way. What I have come up with is this: In a module, there are different environments, one for each different phase of evaluation (runtime, macro expansion time, macro macro expansion time and so on). (This is not a new invention in any way. I just hope that I have copied the concepts correctly.) If you write normal code with no macros, only environment with phase 0 is into play. You get into the next phase in macro definitions or by using the syntax-begin form: (import srfi-1) (syntax-begin (import srfi-13)) (define (a-function) ;; This is inside environment phase 0. ;; Things from srfi-1 are available, but not things from srfi-13. fold) (define-macro (a-macro) ;; Because this is macro definition, this is inside environment phase 1. ;; Things from srfi-13 are available, but not things from srfi-1 (define-macro (an-inner-macro) ;; This is inside environment phase 2. ;; Neither srfi-1 nor srfi-13 are imported in this environment. "hello world") (string-titlecase (an-inner-macro))) The module system's runtime functions (for instance expand-macro and syntax-rules) are available at the REPL and at all environments whose phase >= 1. It's possible to use the module system's runtime in modules' functions, but then you have to explicitly import the module system. This is to make it clear that unless explicitly noted, compiled code is not dependent on the module system. This also makes it easier to tell which modules need to be loaded when compiling a module. Does this make sense? Or am I trying to solve a non-problem? Is this overly difficult to understand? /Per

4 11

Simple module system
by Marc Feeley 30 Mar '09

30 Mar '09

Following my experiment converting the "futures" Chicken egg using Gambit's namespace mechanism, I have come up with a pretty minimal set of special forms to do the same thing but more elegantly, namely: ;; (##module <module-name> <language-name> ;; (export <id> ...) ... ;; (define-macro ...) ... ;; ) ;; ;; (##require <module-name>) ;; ;; Currently, <module-name> must be a symbol naming the source file ;; without the extension and <language-name> must be the symbol ;; |gambit|. ;; ;; The ##module form must be the first expression in a file and ;; the ##require form can appear anywhere a definition can appear. I'm attaching the code to this message. Please give it a try and let me know what you think. This is really just a strawman whose purpose is to elicit a discussion on this approach. You can start the "pfib.scm" example with: % gsi -e '(include "modules.scm")' pfib The futures module is no longer split into two files (as it is in Chicken). It is a single file containing the compile and run time parts. It looks like this: ;;; File: "futures.scm" (##module futures gambit (export future touch) (define-macro (future exp) `(futures##make-future (lambda () ,exp)))) (define-type placeholder results condition failed? complete? thread) (define (make-future thunk) ...) (define (touch x) ...) As you can see the ##module form at the top of the file contains all the compile-time information that is needed by a (##require futures). The macro "future" expands into a call to futures##make-future, which is a private function of the module (it is not exported). That's why it contains two sharp signs. The body of the module or macros could contain ##require forms, such as (##require srfi-18). Marc

2 1

Tutorial to black hole.
by Per Eckerdal 28 Mar '09

28 Mar '09

Hello, I have now written a simple tutorial to black hole, explaining use of the basic features. I do it by writing some small web applications in the web framework I am working on. Tell me what you think, especially if there are any things that are obvious to me but not to other people that I should write. http://mwaza.dyndns.org/apps/files/bh-tutorial.html /Per

1 0

Undocumented but at least updated version of black hole
by Per Eckerdal 27 Mar '09

27 Mar '09

Should now be available at http://mwaza.dyndns.org/apps/files/modules.git Beware that this code is under several different licenses! All of them open source, but still. It should be documented in each file. I think that unless otherwise noted, I am the author. Me and Mikael Möre is trying to get it all MIT licensed but we're not done yet. It's late, so documentation will have to wait until later. /Per

1 0

Strawman v2
by Marc Feeley 27 Mar '09

27 Mar '09

I have made small changes to my strawman module system for Gambit to clean up the code, improve performance and allow multiple ##use in a body (I now use ##use instead of ##require). Take a look at the attachment. Per: I checked out the module system you sent to the list (black hole?) and I'm unclear how it is meant to be used. There is no documentation and the 2 examples are really too simple to grasp the possibilities. I could read the code... but I feel it would be best if you gave a quick tour of how your system is supposed to be used. Do I understand correctly that it does not require a "module" special form to wrap the module or be put as a header? An objective I have is to design the Gambit module system so that it can support several other module systems, such as black hole, Jazz, Chicken, Bigloo, PLT, etc. With this feature, a user could access in his code, libraries that come from different communities with their specific module conventions. That would be a great step forward for Gambit! Marc

4 12

Gambit loading extensions
by Marc Feeley 24 Mar '09

24 Mar '09

Hi. Following some brainstorming with Christian Jaeger, Jérémie Lasalle-Ratelle, and Bradley Lucier last week I have returned to thinking about runtime system extensions that would be useful for modular programming. Concurrently Guillaume Cartier was working on improving the startup time of Jedi. Guillaume expressed the need to statically link some of the modules of the Jazz system into the executable (to avoid the startup delay caused by accessing the filesystem for many small modules). He would like the modules to be linked into the executable, but *not initialized*. Instead the modules should only be initialized if and when they are actually used by the application. One of the things that we (excluding Guillaume) did during the brainstorming was to look into some Chicken eggs to see how they are organized, and how they could be used within Gambit with little or no changes to the egg source code. It turns out that Gambit's namespace system provides most of what is needed (although the FFI may need small extensions for some eggs). One thing that came up was the need to ensure that a module would be loaded at most once. This is because a given module may be required by multiple modules that are required by the main module/program. For example the main module A may require modules B and C, and both B and C require module D. Simply putting a (load "D") at the top of B and C will end up loading "D" twice. During our brainstorming I proposed a "load-once" procedure which would maintain a table of the previously loaded modules so that a module would only be loaded once. There are two issues with this: 1) How are modules identified? In other words what is the key that is used to access the previously loaded module table? One simple approach would be to use the filename as the key, but this does not work in a static linking model where the modules have been linked with the executable (and the executable is meant to be installed on a different machine). So what is a good way to identify modules unambiguously? A hash? A user supplied "module id"? Should modules have version numbers? 2) For interactive development there is a need to force the loading of modules, even if they have been loaded already. How should this be expressed by the user? If you have some thoughts about these issues please tell! Marc

3 5

Status on module system dev?
by Mikael More 18 Mar '09

18 Mar '09

Guys, What is the status on module system development? What are the next steps? Mikael

2 1

Re: [Gambit-modules-list] [gambit-list] Using Snow from Gambit?
by Marc Feeley 02 Mar '09

02 Mar '09

On 2-Mar-09, at 5:22 PM, Paul Onions wrote: > On 2009-03-02 21:07:39 +0000, Marc Feeley <feeley(a)iro.umontreal.ca> > said: > >> As for documentation, did you check the Snow web site? > > Hello Mark, > > Yes, I read all the documentation, but somehow I had the preconceived > notion (entirely my own invention I think), that I would be able to > use > Snow's packages in my own work with Gambit. Thanks for putting things > into context for me. > >> The Snow project is fairly dormant right now. I was hoping it would >> catch on with users, but after a short while it was clear that it >> would take a lot of work to convince people to contribute to Snow and >> make it evolve. > > Seems a shame that all that effort is going to waste. Well... who said Snow had ended? I'm sure it will live on in one form or another... for example it could be an important part of the Gambit module system. Marc

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Gambit-modules-list Mars 2009