Hi Robby - <br><br>While I agree that versioned spec is the right thing to do, I do find version-less spec less frustrating to use when trying to find a version that works on 360 (Yes still a newbie that relies on officially blessed version ;P) - some of the libs just iterates too fast and it's never clear which lib version works with which PLT version from the docs, and it became a guess game. This issue of course can be solved with many different ways, but for now version-less spec works.
<br><br>My 2 cents ;) Thanks,<br>yinso <br><br><br><div><span class="gmail_quote">On 5/11/07, <b class="gmail_sendername">Robby Findler</b> <<a href="mailto:robby@cs.uchicago.edu">robby@cs.uchicago.edu</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">FWIW, the version-spec-less planet path specs are really only meant<br>for REPL development, not for real programs. Probably best to put a 1
<br>at the end there.<br><br>Jacob: maybe it is time to get rid of those?<br><br>Robby<br><br>On 5/11/07, Danny Yoo <<a href="mailto:dyoo@cs.wpi.edu">dyoo@cs.wpi.edu</a>> wrote:<br>> > Would it be possible to do the same with the SRFIs?
<br>> ><br>> > When referencing them in the code, we can use names like "strings"<br>> > "lists", etc. and the interpreter will just translate that to the proper<br>> > number without us needing to know or even see the number.
<br>> ><br>> > Then when SRFI-300 comes along and replaces SRFI-1, all you need to do<br>> > is to update this translation table. Just my 0.02... At least it<br>> > *sounds* simple :)<br>><br>> Hi everyone,
<br>><br>> Hmmm... Ok, got it. It's doable with the existing infrastructure in<br>> PLaneT. It'd be very direct to create a PLaneT package that aliases the<br>> common SRFI modules.<br>><br>> This I have now done, since it seems like doing this from the official
<br>> srfi-collection is the wrong thing to do. Chongkai, you don't make the<br>> change to the srfi collection then. I've submitted a PLaneT package that<br>> does absolutely nothing but provide the SRFI names:
<br>><br>> <a href="http://planet.plt-scheme.org/display.ss?package=srfi-alias.plt&owner=dyoo">http://planet.plt-scheme.org/display.ss?package=srfi-alias.plt&owner=dyoo</a><br>><br>> As a concrete example:
<br>><br>> (require (planet "list.ss" ("dyoo" "srfi-alias.plt")))<br>><br>> or<br>><br>> (require (planet "string.ss" ("dyoo" "srfi-alias.plt
")))<br>><br>> should now work.<br>><br>><br>> Since it's PLaneT, this isn't officially sanctioned, so that should<br>> resolve the objections about doing this on the official srfi collection.
<br>> And it still preserves what I wanted before: being able to get at the<br>> common srfi's without having to remember their numbers. So it works out.<br>><br>> (And if an SRFI does pop up with a name that conflicts with existing
<br>> names, I could now choose by dictatorial fiat how to resolve the<br>> conflict... *grin*)<br>><br>><br>> Hope this helps!<br>> _________________________________________________<br>> For list-related administrative tasks:
<br>> <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br>><br>_________________________________________________<br> For list-related administrative tasks:
<br> <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a><br></blockquote></div><br>