[Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
On 16 Nov 2013 22:16:27 +0100, Jörg F. Wittenberger 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
Re: [Readable-discuss] xyzzy: double code execution
On 16 Nov 2013 21:05:11 +0100, Jörg F. Wittenberger wrote: > Replying publicly. > I decided that the way of least resistance to solve this is to introduce a > new namespace and keep the backward compatible code. See also > http://askemos.org/A0cd6168e9408c9c095f700d7c6ec3224?_v=search&_id=1550 for > the XSLT/XML embedding. That makes sense. Good solution. > However I have something else in mind atop. I'd like to look into mixing > markdown as a "front end syntax" and re-parse / pattern match data content > from the resulting XML syntax tree. See: > http://askemos.org/A0cd6168e9408c9c095f700d7c6ec3224?_v=search&_id=756 > (Note: there's also a related remark: neither basic Scheme `read` nor > sweet-read and friends will include comments. For some reason I'd like to > be able transform source code _including_ comments into derived versions, > which will then be the new version presented for edits by human authors. > Ergo: I need those comment nodes to be retained and included with the > corresponding "write" alike operation.) Hmm. The current reader obviously doesn't support that. Our current reader does call "attach-sourceinfo" to allow attaching line/column positions to objects as they are read in. That makes debugging more pleasant, when it's implemented as something other than a no-op. However, comments are not objects, so that won't help you. Are you sure you need it, though? Why not have two readers, once that reads sweet-expressions, and a separate one that skims looking for specially-formatted comments? Then you don't need to figure out how to make them work together. After all, you can control the acceptable input format... just choose an easy one. And if that doesn't work... I guess we could add a nonstandard mode that inserted special objects so you can record comments. I don't know if that would meet your needs, and it'd clearly be a special case not normally used. I'm not even sure how to generate all cases nicely. Most people expect "read" to DROP comments :-). --- David A. Wheeler -- 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
Re: [Readable-discuss] Supporting SRFI-110 in chicken (Joerg Wittenberger)
Am 15.11.2013 15:11, schrieb David A. Wheeler: > The current code includes: >>> ; Default guile stack size is FAR too small >>> (debug-set! stack 50) > ... > > On 15 Nov 2013 11:53:15 +0100, Jörg F. Wittenberger: >> So what is this "debug-set!" - does this have to be called for each >> t-expr-catch call? Or would it be enough to call this once in the >> initialization of the code? > > The name of "debug-set!" is misleading. It's a guile-specific call that > lets you set low-level configuration values. In particular, the default > guile stack size is absurdly small, causing crashes on even relatively > simple parses. > > Yes, it'd be perfectly fine to set it on initialization, not on each > invocation. That really should be moved into an "initialize" function, > and then the guile-specific version calls debug-set!. Will go there. I intent to make the code compile for chicken and rscheme and with your help to not break guile. >> You comment about "old guile" refers to the use of guard/raise at all, >> doesn't it? > > Not just that, it's version numbers of guile. The current stable release > of guile is 2.0.9. But the guile on Cygwin is version 1.8.7, and Alan has > a case where he has to use guile version 1.6. Let me put my question differently: do we HAVE TO support some guile version, which does not have guard/raise? Also: rscheme does (by itself) not have guard. The code would have to have three versions at least... 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. > > >> I see to solutions: a) cond-expand on guile the definition of >> t-expr-catch right where it is b) move this definition into the >> compatibility section. The latter would be better to keep the >> compat-stuff together, the former would cluster the code according to >> the logic. I'd prefer the former. How about you? > > I want the latter - please move things into the compatibility section. > Otherwise the code will over time get very hard to read, because it'll > be completely cluttered with "if system1... else if system2". > If the code just calls "init-sweet-expressions" (for example), then the > compatibility layers can define what that is for various circumstances. > > In general I'd like it to be R5RS, R7RS if we need it, and then use > various procedure and macro definitions to paper over the differences. 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. > > >> The "raise" I'd suggest to do like >> >> (define-syntax raise (syntax-rules () ((_ x) (throw x))) >> >> in the compat section for guile and keep the srfi-34/r7rs compatible >> code in the main body. > > Agree I overall. One nit: old guiles (<2) don't have define-syntax. This > is not a problem, we can just use "defmacro" in the guile-specific > portability layer, and syntax-rules where needed for other > implementations. The kernel.scm code has an example of it, it's not > complicated. Yeah. RScheme also has define-macro only. > >> So how would this work for guile? Does it have a string->keyword? Or >> was is a symbol->keyword? > > We've already implemented keywords for guile, actually. > It's symbol->keyword (good guess!), and in guile keywords begin with "#:". > See parse-hash for details. 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. This is going to be some massaging. But I'm confident that the changes are not too excessive. Best /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
Re: [Readable-discuss] xyzzy: double code execution
Am 15.11.2013 15:29, schrieb David A. Wheeler:
> (Replying briefly privately, since it was sent privately - I'd be happy
> to discuss this further publicly.)
Replying publicly.
>> Here an example. I have so many of them ("grep begin *.xml" indicates
>> 162 in a single directory) that I'm asking myself where it would be
>> worth convince you that there should be a switch to disable the "initial
>> indent cancels indent processing".
>>
>>
>>
>>begin
>> define selected
>> form-field (gi (current-node)) (message-body msg)
>> if (or (not selected) (string-null? (data selected))) (current-node)
>> selected
>>
>>
>>
>> You see: the whole (srfi-49) code is indented to match the XML indent
>> level. In practice I did not always make it match exactly. But often
>> enough I avoided to start in the left column because I felt this would
>> confuse the reader. (Maybe it would not, but who cares.)
>
> We intentionally didn't support starting full expressions in arbitrary
> columns; that turns out that there is a nasty syntactic ambiguity. See:
> http://srfi.schemers.org/srfi-110/srfi-110.html#disabling-indentation-processing-with-an-initial-indent
That ambiguity is the reason why there is always a `begin` block and no
empty line in the idiomatic use. We've been living with SRFI-49 till now.
I decided that the way of least resistance to solve this is to introduce a
new namespace and keep the backward compatible code. See also
http://askemos.org/A0cd6168e9408c9c095f700d7c6ec3224?_v=search&_id=1550 for
the XSLT/XML embedding.
> If you modify your Scheme-from-XML extraction code to look at the
> initial indent of the first line, and then remove that text sequence from
> every line of that fragment, the problem would disappear. And you
> wouldn't need to modify any contracts.
>
This would add yet another layer of complexity. If not done in the
sweet-parse, I'd have to duplicate this indent processing behind some
custom port's i/o, for which I don't see portable code any time soon.
However I have something else in mind atop. I'd like to look into mixing
markdown as a "front end syntax" and re-parse / pattern match data content
from the resulting XML syntax tree. See:
http://askemos.org/A0cd6168e9408c9c095f700d7c6ec3224?_v=search&_id=756
(Note: there's also a related remark: neither basic Scheme `read` nor
sweet-read and friends will include comments. For some reason I'd like to
be able transform source code _including_ comments into derived versions,
which will then be the new version presented for edits by human authors.
Ergo: I need those comment nodes to be retained and included with the
corresponding "write" alike operation.)
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
