KSL [was Re: Introduction and RFC]
scolebourne at btopenworld.com
Mon Oct 29 11:49:10 PDT 2007
That sounds exactly like what I think we're missing ATM :-)
Neal Gafter wrote:
> After the migration to mercurial is complete, I am considering creating
> an open-source project at openjavac.net <http://openjavac.net> as a
> feeder project into KSL, with a hopefully lower barrier to entry. The
> idea is to provide a centralized place to host mercurial patchsets for
> proposals until they're more cooked.
> On 10/26/07, *Stephen Colebourne* <scolebourne at btopenworld.com
> <mailto:scolebourne at btopenworld.com>> wrote:
> The KSL is great in theory, but it has yet to prove its value in
> practice. As far as I know, there have been no changes committed to KSL
> that separate it from javac.
> In addition, KSL has a high barrier of entry (in terms of fulfilling
> the many things that compiler writers and language designers should do,
> including documentation, spec writing and tests).
> Of course, none of this is wrong, it just may signal that 'we the
> community' need to create another project separate from KSL where there
> is a much lower barrier of entry, but as a result a higher risk that the
> compiler/resulting code will be broken. ie. a place where ideas can
> actually be investigated.
> PS. This discussion about KSL probably should be on the KSL list, but
> thread-wise it makes sense here for now.
> PPS.I should also note that I originally signed up here as the KSL
> project webpages told me to do so, so the fact that there is now a KSL
> mailing list is rather a surprise.
> Frederic Simon wrote:
> > I really thought that the KSL was created exactly for that: Filtering
> > language proposals. But there are no mailing lists for KSL pure,
> and the
> > Bug database should not be populated with KSL noise.
> > About KSL, in my experience adding some code to javac (pure
> > implementation) to support small language proposal, is a lot
> faster and
> > cheaper than:
> > - Evaluate the coherence/readability
> > - Evaluate its usefulness (in writing code and API)
> > - Evaluate its impact on current API
> > - Evaluate the risk impact on the javac and JVM
> > So, the KSL is great. Have it, play with it, throw it away (and "may
> > be", "sometimes", "rarely", "occasionally": keep it). And it does
> > have to be Sun employees doing the steps. For me, once a language
> > proposal and RFE entry starts to get momentum (votes and so on),
> so the
> > team leaders as decided in the GB (Sun for the moment) can get
> > and evaluate the next steps.
> > The KSL for me is "Extreme Agility", and luxury of having the
> > implementation before deciding if you need it or not.
> > So, please keep the spirit of it, it's good for everyone.
> > On 10/25/07, *Dalibor Topic* <robilad at kaffe.org
> <mailto:robilad at kaffe.org>
> > <mailto:robilad at kaffe.org <mailto:robilad at kaffe.org>>> wrote:
> > Ted Neward wrote:
> > > Interesting--which list *would* be the proper place to discuss
> > language
> > > proposals? Is there one? (Personally, I thought it was
> this one.)
> > >
> > I think the kitchen sink language project is the venue you
> are looking
> > for: https://ksl.dev.java.net/
> > cheers,
> > dalibor topic
> > --
> > http://freddy33.bglogspot.com/ <http://freddy33.bglogspot.com/>
> > http://www.jfrog.org/
More information about the compiler-dev