[plt-scheme] Questions on PLT status and project structure

[I'll probably repeat some of the things said...]


On Oct 14, Scott McLoughlin wrote:
> First questions regard performance. First, is there an inlining
> directive (or delcaration or proclamation, etc.)

No, the compiler decides what to inline.  (IMO, this is better than an
inline directive -- it's true that you're getting a "one size fits
all" kind of a decision, but it's made by someone who knows about it
much more.)  See the decompiler to look over the code that the
compiler generates, if you're wondering if something gets compiled or
not.

If you *do* need to control inlining -- especially if you need it for
large chunks of code that the compiler will usually avoid, then you
can use macros.  Given some very basic compiler optimizations, this is
a very sane path to take -- for example, see the code in
"collects/scheme/private/sort.ss": after I wrote the code, I moved it
all into a macro, then used the macro a few times, which means that
there are several versions of sorting that get compiled for different
kinds of inputs -- and the compiler can optimize them well.


> Second, are there type proclamations to speed up common fixnum
> arithmatec, vector indexes, etc.

No.  Instead, there is a new `scheme/unsafe/ops' module that provides
you with unchecked versions of operations that you can use to make
things run fast.


> Is there are role for typed-scheme here?

Yes.  Currently, it doesn't do anything -- but consider that
`scheme/unsafe/ops' thing -- it provides some low-level functionality
that runs fast but it is unsafe.  Typed scheme might be used in the
future to wrap this in a safe module by forcing code to type check
before compiling code that calls the unchecked functions in that
module.


> Second questions reqargd PLT as an open source project. Are there
> good documents on PLT internals and optimization/compilation
> strategies? Is there are formal "front end" vs.  optimizations
> vs. "back end + more optimizations" style architecture to the
> compiler?

There are some descriptions in the "src" directory, I think.  Probably
not at the level that you're hinting at.  There is also the "inside"
manual, but that's something that is intended for writing extensions
more than a documentation of how things like the compiler are
designed.


> A simple matter of fact, is there a considerable number of community
> contributors to the "core group" working on the PLT compiler

No.


> and runtime system itself?

That depends on what you consider as runtime -- "core" functions?  GC?
Threads?  IO?


> Fourth, Is there a formal roadmap for the Planet libraries - a sort
> of wishlist from the core development group or user community
> vote/consensus.

How could there be?  Planet is intended for people who want to share
code.


> Similarly, is there an up to date raodmap for the core PLT system?

No, unless you consider piles of todo lists to be roadmaps.  Note that
that's not saying that there is no communication, quite the opposite.
Also, there are some big-goal-next-thing to work on areas.


> Fifth, how well is the PLT system structures towards becoming a 
> user-driven open source project?

It is user driven in the usual sense.


> To boil all this down to a general scheme community question, PLT
> has become *very* popular in the scheme community (programmer
> community, to a lesser degree) at large.  How stable a platform does
> it present for a future canonical open source project should the
> academic group behind PLT abandon the platform for one reason or
> another (lack of funding, changing research focus, etc.)

The "academic group behind PLT" is big enough that the chances that
everyone will wake up one day and realize that they want to teach
early French literature are very slim.  In addition, there's a good
number of people outside that group who are interested.  (Nothing
surprising, really.)




On Oct 14, Robby Findler wrote:
> On Wed, Oct 14, 2009 at 6:19 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> >
> > Speaking for myself, I can't think of anything that would make me
> > give up on PLT. I would guess that most would say the same.
> 
> I certainly would.

Me too.

I think that the conclusion here is that if *all* funding is lost one
day, and everyone involved needs to go out and get ... um ... real
jobs, then you'd see the same kind of people continue to work on the
project, only as a side thing in addition to these jobs.


On Oct 14, Scott McLoughlin wrote:
> I guess I'm noticing that PLT doesn't have exactly the same
> structure as some other popular open source projects.

My guess is that you're doing some comparisons that might be
misleading.  Take any open source *language* project, and see how many
people work on the actual core -- even in cases of non-academic
languages, there is usually a very small core, and often there's some
single dictator for the language.


> These other project structures encourage community participation
> (from qualified community members in different realms) in the PLT
> project offering it a longevity beyond the activities of the core
> group.

IMO such longevity is there, given the above.  (Seems like you're
equating "PLT" with "a group of people who only do this for an
(academic) living, and might wonder off tomorrow if they get tempted
by Some Big Company".)


> I'd hate to see the same happen the PLT, especially has I plan to
> use it for a reasonably large and complex projects.

As Shriram said, it's been there for a long while.  Chances are that
it will survive long enough for your needs.


> I don't mean to propose anything radical hear. Just setting the
> docs/environment up for greater community participation in the
> language and libraries development - bringing it in line with the
> structure of many other open source projects, several much larger
> than the PLT project.

What does other projects have that PLT lacks?  (Not a rhetorical
question: I'm wondering what concrete examples you have in mind.)


On Oct 14, Scott McLoughlin wrote:
> Casey Klein wrote:
> >
> > Of course, the compiler sometimes in-lines non-primitives too.
> 
> Yes, I can see how calls to sibling module functions can be treated
> specially by the compiler.

Just to clarify: the compiler inlines non-primitive functions often,
but IIRC, it doesn't do that across modules.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!