KSL [was Re: Introduction and RFC]

Stephen Colebourne scolebourne at btopenworld.com
Mon Oct 29 11:49:10 PDT 2007


That sounds exactly like what I think we're missing ATM :-)
Stephen

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
>     all
>     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.
> 
>     Stephen
>     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
>     not
>      > 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
>     involved
>      > 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 mailing list