[gambit-list] Gambit-list Digest, Vol 111, Issue 9

Răzvan Rotaru razvan.rotaru at gmail.com
Mon Dec 9 16:07:19 EST 2013


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 at iro.umontreal.ca> wrote:

>
> ---------- Forwarded message ----------
> From: Marc Feeley <feeley at iro.umontreal.ca>
> To: Bradley Lucier <lucier at math.purdue.edu>
> Cc: Logiciel Gambit <gambit at iro.umontreal.ca>,
> gambit-list at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20131209/7029c4b4/attachment.htm>


More information about the Gambit-list mailing list