On 16 Nov 2013 22:16:27 +0100, Jörg F. Wittenberger <joerg.wittenber...@softeyes.net> wrote: > Will go there. I intent to make the code compile for chicken and rscheme > and with your help to not break guile.
Perfect! > Let me put my question differently: do we HAVE TO support some guile > version, which does not have guard/raise? Sadly, yes, but it may not be as bad as you think. I suspect we can create an adequate guard/raise implementation using macros for guile < 2. Then the main code body can use guard/raise. So the main code would "use" guard/raise, or at least give the appearance of doing so. > Also: rscheme does (by itself) not have guard. The code would have to have > three versions at least... But rscheme does have an exception-handling mechanism: http://www.rscheme.org/rs/b/0.7.3.4/5/html/x3020.html So we can probably take the same approach - use macros to create portable scaffolding. Worth trying. > But maybe that's not even relevant. > > It occurs to me that the only use of catch/throw is IMHO stylistic > questionable. In general it's seen as bad style if exceptions are caught in > the course of normal operation. It might be more appropriate for me to > first understand the code - which failed a minute ago. At the moment I > suspect here we have such a case. Maybe a slight restructuring could avoid > the whole construct. Exceptions are only thrown when there are syntax errors, and those should *not* be part of normal operation. They're only thrown by "read-error". It would be possible to avoid the use of exceptions, of course. On approach would be to modify read-error to return some "error signaling" value, and modify at least the combining routines conse, appende, list1e, list2e, and monify. But I suspect there are many other paths that would need to be changed. Doing without exception-handling is error-prone, which is why many languages have them. Scheme generally have exception-handling systems, and they are finally standard in R6RS/R7RS. > As to wish lists: at the moment I have no need use for `set-read-mode`. > Once I'm there I'll want this thread-safe. I'd turn toplevel variables it > modifies into parameter objects. If there are no objections. I like thread-safe, but that would change the interface significantly, yes? > Yeah. RScheme also has define-macro only. Okay. If it has similar semantics (likely), we can probably use the same tricks. > I've seen that. Back to the wish list. > > I'd like the code to be flexible and not restrict the user to one keyword > syntax. But I also need a way to do just that. I need a keyword syntax > implementation, which is independent from the underlying Scheme. Great! I suspect others will want that too. The main syntaxes I've seen are prefixed "#:" and terminating ":". If either can be turned on & off, with reasonable defaults depending on the implementation, that'd be awesome. One request: please do NOT consider ":" by itself as a keyword. Some use that as a symbol (e.g., for type declarations). > This is going to be some massaging. But I'm confident that the changes are > not too excessive. I agree. Oh, and request to everyone: Please try to provide multiple small and incremental patches. We want to make sure that this code is EXTREMELY reliable, and smaller patches are easier to review for correctness. We have a rather extensive test suite, but I don't want to depend on that as our SOLE determiner of correctness. --- David A. Wheeler ----- End Forwarded Message ----- ------------------------------------------------------------------------------ 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
