Am 17.11.2013 16:04, schrieb David A. Wheeler: > On Sun, 17 Nov 2013 15:17:18 +0100, "Jörg F. Wittenberger" > <joerg.wittenber...@softeyes.net> wrote: >> When looking at set-read-mode I'm not sure it integrates well. >> >> It claims that it should support per-port settings. Does not know how >> to do this and me neither. >> >> However using parameters lends itself to per-port semantics. >> >> All we'd have to export those parameters and get to per-port settings by >> means of parameterize. >> >> Ho about? > We really should support per-port settings. I appreciate the > parameter patch, but making them parameters is kind of a workaround. > > I find no officially-standard way to compare ports. > However, I'm guessing that in practice "eq?" should be able > to determine if two ports are the same or not. If so, > we could create a hashtable of port => portsettings, > and then tweak your parameter patch to use that. > > Anyone else have comments? >
My current believe is, that parameters would actually be the best and most standard compliant way to handle this. Though this might come from a missing understanding about the intended semantics. Using parameters, once could easily have something like (define (sweet-cl-read . args) (parameterize ((common-lisp #t)) (apply sweet-read args))) and you are done. This should read from the port with common-lisp semantics. Though I'm not clear about those reader directives (which I would have loved to be ruled out of their mere existence right from the beginning an even before). If those would change the common-lisp value, then their effect would extend over the very next expression only instead from here to end of input from port. But how do those apply to "load"ed or "include"d code anyway? As to maintaining yet another table just to keep those values port-specific: I'd really not love that. It makes the code much more complex. Withing environments like mine, where there code runs on rather limited hardware, I'd love to know that it does not do so many extra lookup just to learn that (by my definition elsewhere) these values will not change anyway. I don't object to such port specific things in general. But I'd prefer them to be mere optional. Furthermore I'd pessimistic about the feasibility of the hash-table approach: How precisely would we determine when the port must/may be deleted from the hash table? SRFI-69 does not specify hash tables with weak references. Best Regards /Jörg ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
