[gambit-list] Gambit-list Digest, Vol 111, Issue 9
alvaro.castro.castilla at gmail.com
Tue Dec 10 17:25:32 EST 2013
On Tue, Dec 10, 2013 at 7:25 PM, Hendrik Boom <hendrik at topoi.pooq.com>wrote:
> On Tue, Dec 10, 2013 at 10:36:59AM -0500, Marc Feeley wrote:
> > On Dec 9, 2013, at 4:07 PM, Răzvan Rotaru <razvan.rotaru at gmail.com>
> > > 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
> > >
> > > 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.
> > Frankly, I think adopting the R7RS module system (subset or
> > compatible superset) is inevitable. It is relatively simple and I
> > expect it to be adopted by other Scheme implementations, allowing
> > Gambit users to more easily share code with users of other Scheme
> > systems. Also, I know that Alex Shinn is working on a new version of
> > the "snow" Scheme code repository that will be based on the R7RS
> > module system.
> The first thing I thought when reading the suggestion that Gambit
> should standardize on Blackhole was, Where's the Scheme standard going
> with this. Shouldn't we be tending in that direction?
I agree. I believe that Gambit will do itself and the community a favour
following R7RS. Current Blackhole implementation does not deliver, and I
see no real/practical benefit in it vs R7RS. This has been long discussed
in this list. That Snow remake by A. Shinn sounds very promising. I hope we
can integrate that into Gambit.
About having libaries at your fingertips, I totally agree. I tried to help
in this regard, with a minimal set of tools for building, managing
dependencies, task running, and packaging. But as happened to many of us
through the history of Lisp, a single-man effort can oly get you so far.
Eventually "real work" must be done. However, some of the things I achieved:
- Reviewing, collecting and improving as many implementations of SRFI as
possible for Gambit
- Selecting and structuring some of the most important libraries made by
the Scheme community, for Gambit or any other implementation that is or can
be made compatible
- Trying to mimick some of the best "batteries included" libraries out
- Making app "skeletons" for Android, iOS (pending) and desktop platforms,
so the developer could just start working as soon as possible
- Do it with a tiny layer, so the Gambit developer could feel in total
posession of the control, unlike Blackhole where you can't bend the rules
The work is unfinished, but my intention is to continue with this:
- As soon as there is some good / standard implementation of modules,
migrate to it. Currently is working with a custom/hacky-but-working system
that simply automatizes building modules and its dependencies, with total
- Release some apps and tutorials, showing the easiest way to get started
with all this infrastructure in any of the platforms, to get a real app up
and running, totally customizable. I'm following no framwork approach here,
each one could do things in a personal way, but starting from something.
- Release my first real app using only this system, as I'm currently using
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list