Hi,

Congratulations, and a big thank you. This is great news. I remember looking over scheme implementations some time ago, and not being sure whether gambit is actually still alive or not (besides bugfixing). Whether there's a community around it. Whether somebody is till actively working on it and/or supporting it. In the mean time I have learned the answer, and I've also found out that things are moving towards multi-core and multi-platform (speak: javascript). This is great.

If I am allowed, I would like to criticize the lack of a "community adopted" module system, which I think can have a big (positive) influence on the community. My oppinion is that newcomers want to get started quickly. And they have stuff to do. They want to tackle the big questions later, and get stuff done now. Rick Hickey did put it very nicely: default matters. I can't but agree. If Black Hole is good enough, I can't but suggest to give it a "pseudo standard" status and include it in the distribution (or recommend it as a standard module system). And make sure it's handling libraries at least at convenient as maven (i.e. auto download and dependency resolution).

It is incredibly important to have an easy quickstart, and have libraries at your fingertips, and get stuff quickly done. This is actually the secret recipe of Java (even if they discovered it in the second decade, and the core technology still sucks big time, even now). As much as I hate to wake a sleeping dragon, I must say that gambit has to make more bold moves and decisions and focus on gathering a community around it, if it intends to be practical.

Thanks, and don't kill the critique. Razvan

I'm not sure if and how I can help. If there are ideas out there, I'm open to suggestions.

On 9 December 2013 19:00, gambit-list-request@iro.umontreal.ca wrote:

---------- Forwarded message ---------- From: Marc Feeley feeley@iro.umontreal.ca To: Bradley Lucier lucier@math.purdue.edu Cc: Logiciel Gambit gambit@iro.umontreal.ca, gambit-list@iro.umontreal.ca Date: Mon, 9 Dec 2013 09:10:55 -0500 Subject: Re: [gambit-list] [ANN] Gambit-C v4.7.1 released

On Dec 8, 2013, at 2:44 PM, Bradley Lucier lucier@math.purdue.edu wrote:

...

So, Marc, spill the beans! There are thousands and thousands of lines

of new code in this release; what's new? What can we play with here?

This release represents the latest month of work where the runtime system has been refactored to support multiple VMs and multiple threaded VMs (with OS threads). Data structures had to be modified to clarify what is shared between VMs, and what is specific to each "processor" in each VM instance. An abstraction layer was added to interface to the operating system's thread system. The linker was also changed to allow a VM to only initialize the modules it requires. Not much of this work translates to user visible features at this point, but it does put in place a new organization of the runtime system that is necessary for a parallel Gambit. Given that the Gambit compiler's code generation changed (to support the new linker), it was necessary to do a "release", otherwise it would not be possible to build Gambit from the sources on the repo. I'm also interested in having feedback from people building this new release of Gambit. Please report any problems building Gambit on your computer.

One feature that is user visible, and possibly interesting for developers of large applications, is the ability to link modules into an executable, but not "load" these modules when the program is started. This can make the startup of the application faster and use less memory. This is achieved with the -nopreload linker option, the special form (##require-module <name>) and the procedure (##load-required-module '<name>), where <name> is a symbol naming a module.

The form (##require-module <name>) can be placed anywhere a definition is allowed. For example it could be at the file's top-level, inside of a function definition, or the head of a let body. This form adds the call (##load-required-module '<name>) at the *top* of the file. The procedure ##load-required-module causes a linked module to be loaded if it has not previously been loaded. By default the linker loads all the linked modules when the program is started (what I call "preloading" of a module). The linker now has the option -nopreload that can be placed anywhere on the command line to prevent the preloading of the following modules. Here's an example:

% cat a.scm (pp 'hello-from-a.scm)

(define (double x) (* 2 x)) % cat b.scm (pp 'hello-from-b.scm)

(define (fun x) (##require-module a) (pp (double x))) % cat c.scm (pp 'hello-from-c.scm)

(thread-sleep! 2)

(##load-required-module 'b)

(fun 100) % gsc -exe a.scm b.scm c.scm % ./c hello-from-a.scm hello-from-b.scm hello-from-c.scm <2 second pause> 200

Note that the invocation of gsc without the -nopreload option gives the same behavior as previous versions of Gambit: all modules are preloaded in a left to right order.

Here's what happens when the preloading is disabled:

% gsc -exe -nopreload a.scm b.scm c.scm % ./c hello-from-c.scm <2 second pause> hello-from-a.scm hello-from-b.scm 200

Here the program only loads module c (the "main" program is always the last module). It is module c that explicitly requests the loading of module b by calling (##load-required-module 'b). However, since module b has a dependency on module a (in function fun), module b will require the loading of module a before its body is executed. So module a's body is executed before module b's body.

These features form the basis for constructing a module system.

Marc