Re: [Readable-discuss] Discussion: Should leading . in sweet-expressions have wisp semantics?
Am 26.11.2014 um 23:32 schrieb David A. Wheeler: This is a request for comment: In sweet-expressions, should a line beginning with . have the same semantics as wisp? In wisp, I understand that a line beginning with . is interpreted as a sequence of expressions at the same level. E.G.,: foo bar . aaa bbb ccc = (foo bar aaa bbb ccc). A . with a single n-expression is interpreted this way now. Currently, it's illegal to have more than 1 n-expression on a line; this change would relax that rule. Anyway, thoughts welcome, pro or con. For indentation sensitive mode as the first element on a line: I fail to see what damage it could do. = pro However within normal s-expressions or neotheric expressions I'd have second thoughts. How would this be parsed?: foo bar . aaa . bbb ccc Here I'd prefer to get a parsing error. = con /Jörg -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
Am 19.11.2014 um 20:48 schrieb Arne Babenhauserheide:
And for example today Mu Lei (Nala Ginrut) had the idea of
representing sxml templates as wisp - a case where I think the sweet
* * syntax could come in really handy.
I can agree. Using SXML with sweet (in that case) works quite well.
Here a ~100kbyte example application (be sure to read in whitespace
preserving mode; my browser gets it wrong):
http://ball.askemos.org/A60aa8b838c61b0de7e9f3cfd5d3ea0c1
(BTW: This is a payment system based on ricardian contracts; quite
different from bitcoin. Currently being documented. More here:
http://ball.askemos.org/?_v=search_id=1856
http://ball.askemos.org/A5023d27b0e3fce3ee0b12b79e7e337ce
comments welcome.)
Side note: The * * can be problematic if your LISP code is itself
embedded in XML formatted source code. Which for me is the case. (To
escape I allowed the {* and *} as to alias those.)
/Jörg
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Damage done.
Sure CDATA could solve the problem. So could encoding as lt; .
With cdata we'd need to watch that no ]] is in sweet lisp.
Cdata does not work for attribute values.
Many web devs need to be told what cdata actually is.
Most of this embedded code is rather short. The wrapping would - too -
defeat the purpose of a readable source.
On May 9 2014, David A. Wheeler wrote:
David A. Wheeler scripsit:
This would mean that {* x *} would be interpreted *differently* by a
curly-infix reader (or a neoteric reader) compared to a
sweet-expression reader.
On Fri, 9 May 2014 13:37:04 -0400, John Cowan co...@mercury.ccil.org
wrote:
I think that's a killer.
Frankly, this is what CDATA sections were made for. Wrap your Lisp
code in ![CDATA[ and ]] brackets, and is no longer magic.
(Note that is never magic, though there is an escape for it anyway.)
Ah! Of course! CDATA was specifically created for this.
If you can limit yourself to XML (including XHTML) and SGML,
using CDATA sections is almost certainly the best answer.
The one caveat is that HTML doesn't support CDATA directly.
However, if you're just *processing* it as XML, you can always
read it as XML and then transform it however you like.
--- David A. Wheeler
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find
out: #149; 3 signs your SCM is hindering your productivity #149;
Requirements for releasing software faster #149; Expert tips and advice
for migrating your SCM now http://p.sf.net/sfu/perforce
___ Readable-discuss mailing
list Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Damage done.
Hi all,
continuing on alias tokens for collecting lists.
Two aspects have made my feelings stronger that I'd actually like {* and
*}: A) As noted before, users usually know how to key them in. B) My
emacs will make it easy to skip over the block in most editing modes.
To get a feeling what it would take I go my hands dirty. Resulting diff
below. Note that this code is a dirty hack by now. Where
`my-read-delimited-list` returns '* I should probably attach source
info, shouldn't I? Let alone that I tend to believe that the token ought
to be generated more generic. Furthermore there should be a
configuration option to switch it off entirely as the other reader
features already have.
There is one more nice thing if the alias was actually to work correct:
one could drop two more characters from the special set the programmer
has to be aware of and .
So far there is only so much test coverage. But I have not yet managed
to write a test case which returns surprising results.
To my current knowledge there is actually only one user-visible change
besides {* *} becoming an alias for * *: the way one has to actually
get a symbol star read after a {: separate it by white space to avoid
it being taken as opening a collecting list. Is this actually all the
damage it did? What am I missing?
Best regards
/Jörg
--- /media/u/Arbeit/jfw/build/armhf/askemos/ball/mechanism/srfi/srfi-110.scm
2014-02-18 14:26:17.819821953 +0100
+++ srfi-110-ndbg.scm 2014-05-09 13:33:41.296085721 +0200
@@ -1634,9 +1634,19 @@
(my-read-delimited-list neoteric-read-nocomment #\] port)))
((char=? c #\{ )
(my-read-char port)
- (attach-sourceinfo pos
- (process-curly
- (my-read-delimited-list neoteric-read-nocomment #\} port
+ (let ((c (my-peek-char port)))
+ (if (eqv? c #\*)
+ (let ((e (underlying-read neoteric-read-nocomment port)))
+(if (eq? e '*)
+'*
+(attach-sourceinfo
+ pos
+ (process-curly
+ (cons e (my-read-delimited-list
neoteric-read-nocomment #\} port))
+ (attach-sourceinfo
+ pos
+ (process-curly
+(my-read-delimited-list neoteric-read-nocomment #\}
port))
((my-char-whitespace? c)
(my-read-char port)
(neoteric-read-real port))
@@ -1759,14 +1769,20 @@
(let ((c (my-peek-char port)))
(let-splitter (results type expr)
(n-expr-or-scomment port)
-(if (eq? (car results) 'scomment)
+(if (eq? type 'scomment)
results
(cond
((and (eq? expr sublist) (eqv? c sublist-char))
(list 'sublist-marker '()))
((and (eq? expr group-split) (eqv? c group-split-char))
(list 'group-split-marker '()))
- ((and (eq? expr '*) (eqv? c #\))
+ ((eq? expr '*)
+ (if (eqv? #\} (my-peek-char port))
+ (begin
+(my-read-char port)
+(list 'collecting-end '()))
+ results))
+ ((and (eq? expr '*) (or (eqv? c #\{) (eqv? c #\)))
(list 'collecting '()))
((and (eq? expr '*) (eqv? c #\*))
(list 'collecting-end '()))
--- /media/u/Arbeit/jfw/build/armhf/askemos/ball/mechanism/srfi/srfi-110.scm 2014-02-18 14:26:17.819821953 +0100
+++ srfi-110-ndbg.scm 2014-05-09 13:33:41.296085721 +0200
@@ -1634,9 +1634,19 @@
(my-read-delimited-list neoteric-read-nocomment #\] port)))
((char=? c #\{ )
(my-read-char port)
- (attach-sourceinfo pos
- (process-curly
- (my-read-delimited-list neoteric-read-nocomment #\} port
+ (let ((c (my-peek-char port)))
+ (if (eqv? c #\*)
+ (let ((e (underlying-read neoteric-read-nocomment port)))
+ (if (eq? e '*)
+ '*
+ (attach-sourceinfo
+ pos
+ (process-curly
+ (cons e (my-read-delimited-list neoteric-read-nocomment #\} port))
+ (attach-sourceinfo
+ pos
+ (process-curly
+ (my-read-delimited-list neoteric-read-nocomment #\} port))
((my-char-whitespace? c)
(my-read-char port)
(neoteric-read-real port))
@@ -1759,14 +1769,20 @@
(let ((c (my-peek-char port)))
(let-splitter (results type expr)
(n-expr-or-scomment port)
-(if (eq? (car results) 'scomment)
+(if (eq? type 'scomment)
results
(cond
((and (eq? expr sublist) (eqv? c sublist-char))
(list 'sublist-marker '()))
((and (eq? expr group-split) (eqv? c
Re: [Readable-discuss] I've got a problem with the readability.
it just occured to me that |* and *| might be good aliases to * and *
too. If { and } could be problematic.
Just: those in turn... hm, does the sweet read code actually rely on the
read implementation of the underlying Scheme? I had the impression that it
would read char by char anyway.
On May 7 2014, Jörg F. Wittenberger wrote:
Thanks for your anwser.
Am 07.05.2014 15:11, schrieb David A. Wheeler:
On Thu, 01 May 2014 13:58:07 +0200, Jörg F. Wittenberger
Q2: Would it be a good idea to allow this in the official spec?
Embedding in XML seems to have broad uses these days and I foresee use
cases for sweet list especially in domain specific languages.
I really want to keep the spec stable for a while (though that doesn't
stop experimentation with various extensions).
I've done some experiments generating HTML/XML, but like this:
html
! head
! ! title
and with that approach there's no issue.
Sure, that' when *generating* the X/HML. However in my case the XML
parser *always* gets the source code first. And the source is
re-created from the parsed tree upon need. The sweet-read procedure
only sees some element's literal content.
In other words: the users sees all #\ and #\ characters within
sweet-read LISP code always quoted according to XML.
Using {*...*} would probably be a challenge for many implementations.
IIIRC, in the Common Lisp implementation { and } are treated a lot
like ( and ), that is, they are their own tokens, and there's no
real opportunity to re-connect them later. So I'd discourage the use of
{*...*} specifically.
Hm. I must admit that I understand much too little about Common List to
make a qualified statement.
Let alone that I'd dare to judge how hard the implementation would end
up to be.
However: Am I correct to understand that this would be one
implementation problem?
If so, than I'd rather wholesale defer the consideration. In favor of
readability of the source code and being the most natural choise
(whatever that would be ;-).
At the moment I'm behind the language design, since I see this as the
whole point of readable lisp. Once it's clear what would be the best
thing to have, I'd return to consider the hardship of implementation.
At worst that might end up being an iterative process.
Here's an idea: Can you use full Unicode (encoded, say, as UTF-8)?
For a couple of seconds I thought: this genius! I should have though of
that.
You could then use additional pairing markers, there are a whole bunch
in math and quoting markers. Then there'd be no overlap.
For example, you could use the Ogham feather mark pairs:
U+169b Ps OGHAM FEATHER MARK ᚛
U+169c Pe OGHAM REVERSED FEATHER MARK ᚜
Or brackets with quills:
U+2045 Ps LEFT SQUARE BRACKET WITH QUILL ⁅
U+2046 Pe RIGHT SQUARE BRACKET WITH QUILL ⁆
Some folks have tried to create a list of these paired characters here:
https://stackoverflow.com/questions/13535172/list-of-all-unicodes-open-close-brackets
I'm not sure what the best symbols would be... we could try them out on
many systems to see how they look. These could be considered synonyms,
as extensions to the existing system.
But there's the catch: we are still talking about source code to be
keyed in by developers. Some keyboards might have additional pairing
characters. Mine for instance has « and ».
Though from a developers point of view, I'd expect myself to be in a
situation sooner or later, where I need to key them in from a dump
terminal.
That's why I feel we should avoid those here.
After all: If I have to deviate from the spec, it does not matter how
much. The hardship of maintaining an implementation remains.
/Jörg
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] I've got a problem with the readability.
Hi all,
I'm just gaining experience with writing sweet lisp code. Maybe I don't
see the right solution.
I use sweet code in the context of a web application at the moment. The
framework is template based. A page can be plain HTML or - for dynamic
content - elements or attributes in a special namespace are evaluated.
So the sweet expressions show up always as either content or attribute
values in the source. That's fine except for collecting lists. The *
* markers just don't look nice under XML quotation rules: lt;* gt;*.
Too bad.
By design I want tools like xmllint verify my spiced up html source.
I feel I need an alternative marker for them.
Anybody having better idea?
Assuming no better idea:
Q1: Which marker would be good in spirit? I'd propose to use {* and
*} as alternatives since { and } are already taken special anyway.
Q2: Would it be a good idea to allow this in the official spec?
Embedding in XML seems to have broad uses these days and I foresee use
cases for sweet list especially in domain specific languages.
Best Regards
/Jörg
--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] treatment of quote symbol
Am 06.12.2013 07:01, schrieb David A. Wheeler: I'm guessing Joerg Wittenberger wants something else, though :-). So let's talk about that. I just wanted to know whether the current behavior was an accident or intentional. John's reply http://trac.sacrideo.us/wg/wiki/QuoteDelimiter made me aware that I overlooked a compatibility issue within Scheme itself. So I'll eat the food (and insert spaces into my code where they are missing now). /Jörg -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] treatment of quote symbol
Hi all, it's beginning to annoy me: normal Scheme readers treat quote and quasiquote symbols as terminating charachters when reading symbols. With the readable reader they suddenly become part of a symbol. That's all rather confusing and causes so much incompatibility. Its this really intended or just an oversight? /Jörg -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using t-expressions
Am 27.11.2013 02:22, schrieb David A. Wheeler: On Tue, 26 Nov 2013 15:11:39 +0100, Jörg F. Wittenberger wrote: I changed it's signature to match srfi-23 (for know) (: read-error (string rest * - *) Okay, but you'll need to modify the procedure definition to match. Sure. I just did not want to clutter the list with some imature, temporary code. But I tend to prefer a more restrictive, though compatible, syntax in this case (: read-error (string input-port string rest * - *) Please don't. The intent was to be syntactically consistent with error as defined in srfi-23 and R7RS. Someone can always modify the error port to change where it goes. Oh, I presume you mean output-port not input-port there. No, I meant input-port - or rather the fake input port we're reading from. Iff the latter supports getting the position or something, the read-error could report them too. For the moment I just used peek-char to show the problematic character. This signature is compatible with srfi-23 error. It's just a little more specific and should probably itself rely on plain error in the implementation. Whereby I'd require all calls to read-error to pass the port and the last successfully read token in an effort to further improve error messages. Why not just pass last successfully read token as a parameter after the string? That was the intent behind the string after the (fake) input-port. The ONLY procedure that catches an exception is t-expr-catch: (define (t-expr-catch port) (init-sweet) (guard (exception ((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) Is there actually any scheme implementation which benefits from this catching? I can't image. Our processing program does, because it tries to process as well as it can. But we could change the interface. I'd feel it might be good to provide a clean up read like `read-to-unindented-line` to help the implementor of a repl. But for the default it just does not feel right to me. Okay. An easy approach would be to raise an exception on error, and add an option to permit the current behavior (catch and retry). That's an interface change, but the SRFI doesn't define specifics on how to handle errors (since Schemes vary in this matter), and it makes sense that people will want to get errors. Guile 1.8 doesn't support srfi-23 or R7RS, so that would need to be implemented separately on guile. This one does not look to bad to me: https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Error-Reporting.html#Error-Reporting /Jörg -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
Am 27.11.2013 02:28, schrieb David A. Wheeler: I said: At the least, I could put things in different files, and then use cat to create files usable to different systems. On Tue, 26 Nov 2013 14:47:36 +0100, Jörg F. Wittenberger: Not too bad and idea. While it might not scale to whole programs, it's certainly a valid way to get things done for something the size of a srfi's implementation. Right. This thing is small. I don't see anything good for trivial preprocessing: * scmxlate appears too complex to get going. Probably. A few bullet point about my take on this. 1) Whatever we do here, it's not necessarily going to be used for real but merely to show how things would have to be processed in users build. 2) From (1) I conclude: the least amount of commonly available tools is the best. 3) When pre-processing LISP code, the best language for the job is actually LISP, since it has easily access to the structure of the code to be rewritten. Other languages are forced to go through axillary properties of the code. cpp, as you said, is a disaster for LISP and m4 is a disaster in itself. 4) Point (3) is mostly incompatible with (2). The only exception might be recent GNUmake. I did not yet have the time to check it out, but I read it would support guile. Maybe one could trick it into running a guile pre-process. 5) Coming back once more to my desire to have a Scheme reader which would allow to deliver a modified AST including comment nodes: such a beast could be used to write back-and-forth (round-trip-safe) code to code transformations. One could work with any flavor when porting to new implementations and easily roll the result back into the generic form. All this should need would be the generic base and a guile-as-in-gnumake specialized version. Let me add: I'm not entirely sold to (5) but I'd like to see how this would work in reality before I judge. * cpp is a disaster for Lisp (it wants to parse '...' as character constants) * m4 is easy to get wrong, and has too much functionality. I think I could create a simple #ifdef ... #elifdef... #else... #endif preprocessor in awk (which is in the POSIX standard) that would do the job. If I dug deep enough into the code I ever wrote, I guess I could come back with at least two such things in KR C. ;-) I'm not sure it's worth to write a special tool just for this special case. Then the whole thing could be in one file, and generate variations for different purposes. For those Schemes with cond-expand, we could put them in one file, so we wouldn't have to generate too many files. Since the single-file approach would still require some pre-processing, let me suggest yet another single file approach: shar. A shell archive including several files a little sh-script to glue the pieces together. Still one file. ;-) Irony aside: any tool will do. Simplicity for the end user should be the trumping argument. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
Am 25.11.2013 23:16, schrieb David A. Wheeler: David A. Wheeler scripsit: How about cond-expands at the beginning to handle much of the shimming, On Mon, 25 Nov 2013 12:08:47 -0500, John Cowan co...@mercury.ccil.org wrote: As of the last time I looked, cond-expand wasn't supported by Racket, Scheme48/scsh, Larceny, Ypsilon, S7, or Sizzle. Whow! What an impressive list! It just gets worser and worser. Putting the text in *different* files and leaving them there *also* appears to be non-portable: * R5RS load doesn't guarantee that loading is relative to the directory of the current file (or provide any other guarantee about current directory), and has no include at all. * R7RS does have include (4.1.7. Inclusion), though it merely encourages searching the same directory as the caller of include (and certainly doesn't guarantee searching there FIRST, so it's just begging for security vulnerabilities just like PATH=.:$PATH). Plus: different compilers will need specific care anyway. After all, you don't want to use load at all, since it may compile into a call to load with a given file name, which defeats the very purpose of compilation. Maybe it's time to break out cpp or sed :-(, or use some other tool to generate various files for different Scheme implementations. At this point it might be rather easy to explain a second (and more general) use case of my idea of having a Scheme reader which returns comments are nodes in the AST. I already wrote such a tool for my own purpose (even though does currently not include comments in the translated files, which is not bad in principle, but still bad in practise). Helps me to expand cond-expand sections, overcome my inability to get hygienic macros work in rscheme and expand some parsers written using lalr for chicken. It even implements the make macro from PLT (which I tested by writing a replacement of the make process for chicken)... Neatly a tool but see below... The configure program already modifies the file anyway, so that might not be insane. Hm. Depends on the stance you take wrt. configure. ;-/ At the least, I could put things in different files, and then use cat to create files usable to different systems. Not too bad and idea. While it might not scale to whole programs, it's certainly a valid way to get things done for something the size of a srfi's implementation. I'll note that my Common Lisp implementation just works, and it even overrides the reader. In contrast, a common answer seems to be don't bother trying to write portable Scheme: http://stackoverflow.com/questions/11062320/writing-portable-scheme-code-is-anything-standard-beyond-r5rs-itself Thanks for this pointer. It took me to http://www.ccs.neu.edu/home/dorai/scmxlate/ which I have not yet heard about. There is so much we don't ever see. Maybe I can retire the preprocessor mentioned above. Though probably not: just found out that at minimum I would have to add rscheme to scmxlate. Also it seems a bit hard to use and even harder to use in batch mode. I *like* Scheme, but it's starting to feel like an abusive relationship :-). Yeah, sometimes I feel that way too. John, how do you manage to keep a positive mood when dealing with so many implementations? -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using t-expressions
Am 25.11.2013 15:14, schrieb David A. Wheeler: On Mon, 25 Nov 2013 12:24:23 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: Hi all, I'm just making my first experiences in actually using srfi-110. At this point I find myself forced to make serious changes to the program logic. Beyond what's supported by simply configuring the source code. The worst thing I found that it will complain on the error port when reading badly formatted code and then continue to read. I really, really need it to do what other Scheme readers usually do: error out. Easily done, and there are many ways to do it. The ONLY procedure that throws an exception is read-error: (define (read-error message) I changed it's signature to match srfi-23 (for know) (: read-error (string rest * - *) This allows me to do as better job at error reporting. But I tend to prefer a more restrictive, though compatible, syntax in this case (: read-error (string input-port string rest * - *) Whereby I'd require all calls to read-error to pass the port and the last successfully read token in an effort to further improve error messages. But I'm unsure about this. Any comments? (display Error: (current-error-port)) (display message (current-error-port)) (newline (current-error-port)) (flush-output-port (current-error-port)) (raise 'readable) '()) The ONLY procedure that catches an exception is t-expr-catch: (define (t-expr-catch port) (init-sweet) (guard (exception ((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) Is there actually any scheme implementation which benefits from this catching? I can't image. I'd feel it might be good to provide a clean up read like `read-to-unindented-line` to help the implementor of a repl. But for the default it just does not feel right to me. /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] using t-expressions
Hi all, I'm just making my first experiences in actually using srfi-110. At this point I find myself forced to make serious changes to the program logic. Beyond what's supported by simply configuring the source code. The worst thing I found that it will complain on the error port when reading badly formatted code and then continue to read. I really, really need it to do what other Scheme readers usually do: error out. The surrounding Scheme system ought to know what to do with errors. Those Scheme systems I know do all catch the error and print it out on the error port - by default. This is usually done in the repl and allows applications to catch the error for app specific handling. For instance: my application evaluates the code within a sandbox from a web server. Message at the error port are in this context only for errors in the implementation and end up in the error log file. What's even worse: simply complaining and the *continue to read* as if nothing had happened results in strange, stupid and wrong messages from the interpreter caught later. Example: an error in (define x ..) ends up and x unbound. Quite irritating. Should this become yet another config option for the code, or should we simply resort to the more standard behavior and error out via srfi-26 compatible code? Best Regards /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
Did I say next week? I should rather do something else, but I can't fight myself. :-/ Bad news this time. Am 22.11.2013 14:59, schrieb David A. Wheeler: On Fri, 22 Nov 2013 10:26:58 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: Why all the redefines from body to read-body? We normally use the same name as per the grammar. RScheme idiosyncratic: `body` is already a bound elsewhere within some code required com compile this code. Hence RScheme complains about the semantic error and that redefinition would break things. The only reasonable way I saw was to change the name to avoid the conflict. However by re-considering the case now I understand that the desire to keep `body` there literally to match the grammar. In that case we should macro-define body into read-body for RScheme only. If Rscheme will accept that without complaint, that'd be very nice. Otherwise, I'm happy to rename definitions to make it work... I just want to minimize it, and document why there's a variance when it happens. I'd now rather take back my suggestion to macro-define around: while it would work for the call site, I have no (good) idea how to change the definition. Furthermore bad news regarding the idea to move those cond-expand's into the read-able-module-contents. The problem is not cond-expand, but rscheme accepts define-macro only at top level. The attached patch has a strange name in a way, considering that it contains much more than this. However it also fixes a bug in n-expr-or-scomment. David, could you merge this into the git repo? The next thing I'd try to get around would be making those settings port specific. But I'd rather like to keep those diffs size down. Best Regards /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
Am 23.11.2013 11:28, schrieb Jörg F. Wittenberger: The attached patch Which attached patch you ask? Here we go. --- kernel.scm.orig 2013-11-23 11:16:19.0 +0100 +++ kernel.scm 2013-11-23 11:17:14.0 +0100 @@ -176,6 +176,97 @@ (define-module (readable kernel))) (else )) +; Chicken compatible type annotations. Ignored on other platforms. +(cond-expand + (chicken + (define-type :reader-proc: (input-port - *)) + (define-type :reader-token: (pair symbol *)) + (define-type :reader-indent-token: (list string *)) + (define-syntax no-values (syntax-rules () ((_) (void + ) + (rscheme + (define-macro (: . x) #f) + (define-macro (no-values) (values)) + ) + (else + (define-syntax : (syntax-rules () ((_ . rest) #f))) + (define-syntax no-values (syntax-rules () ((_) (if #f #t + )) + +; Implementation specific extension to flush output on ports. +(cond-expand + (guile ; Don't use define-syntax, that doesn't work on all guiles + (define (flush-output-port port) ; this is the only format we need. +(force-output port))) + (chicken + (define-syntax flush-output-port +(syntax-rules () ((_ port) (flush-output port) + (else )) + +; Special cases for those Scheme implementations which do that not +; support define-syntax. +; Note that guile is a large special case further down. + +(cond-expand + (rscheme + + (define-macro (readable-kernel-module-contents exports . body) +`(begin ;; (export ,@exports) + ,@body)) + + (define-macro (let-splitter (full first-value second-value) expr . body) +`(let* ((,full ,expr) + (,first-value (car ,full)) + (,second-value (cadr ,full))) + . ,body)) + ) + (else +; assume R5RS with define-syntax + +; On R6RS, and other Scheme's, module contents must +; be entirely inside a top-level module structure. +; Use module-contents to support that. On Schemes +; where module declarations are separate top-level +; expressions, we expect module-contents to transform +; to a simple (begin ...), and possibly include +; whatever declares exported stuff on that Scheme. +(define-syntax readable-kernel-module-contents + (syntax-rules () +((readable-kernel-module-contents exports body ...) + (begin body ... + ; There is no standard Scheme mechanism to unread multiple characters. + ; Therefore, the key productions and some of their supporting procedures + ; return both the information on what ended their reading process, + ; as well the actual value (if any) they read before whatever stopped them. + ; That way, procedures can process the value as read, and then pass on + ; the ending information to whatever needs it next. This approach, + ; which we call a non-tokenizing implementation, implements a tokenizer + ; via procedure calls instead of needing a separate tokenizer. + ; The ending information can be: + ; - stopper - this is returned by productions etc. that do NOT + ; read past the of a line (outside of paired characters and strings). + ; It is 'normal if it ended normally (e.g., at end of line); else it's + ; 'sublist-marker ($), 'group-split-marker (\\), 'collecting (*), + ; 'collecting-end (*), 'scomment (special comments like #|...|#), or + ; 'abbrevw (initial abbreviation with whitespace after it). + ; - new-indent - this is returned by productions etc. that DO read + ; past the end of a line. Such productions typically read the + ; next line's indent to determine if they should return. + ; If they should, they return the new indent so callers can + ; determine what to do next. A * should return even though its + ; visible indent level is length 0; we handle this by prepending + ; all normal indents with ^, and * generates a length-0 indent + ; (which is thus shorter than even an indent of 0 characters). + + (define-syntax let-splitter +(syntax-rules () + ((let-splitter (full first-value second-value) expr body ...) +(let* ((full expr) + (first-value (car full)) + (second-value (cadr full))) + body ... + )) + (cond-expand ; - ; Guile Compatibility @@ -243,10 +334,6 @@ (debug-set! stack 50) (no-values)) -; Implementation specific extension to flush output on ports. -(define (flush-output-port port) ; this is the only format we need. - (force-output port)) - ; Guile was the original development environment, so the algorithm ; practically acts as if it is in Guile. ; Needs to be lambdas because otherwise Guile 2.0 acts strangely, @@ -455,52 +542,15 @@ (define (type-of x) #f) (define (type? x) #f) - (define (string-keyword s) -(symbol-keyword (string-symbol s))) - ) ; - ; R5RS Compatibility
Re: [Readable-discuss] initial support for rscheme
Am 22.11.2013 04:45, schrieb David A. Wheeler: On Thu, 21 Nov 2013 12:29:58 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: I tried for now to keep the compatibility layer before the actual module. But that might leak definitions (like the rudimentary guard implementation) outside, which would have to be avoided. For this to we would have to move the whole section into the body of `readable-kernel-module-contents`, right? Correct. To the extent that we *can*, I think we need to move things inside the macro that creates the module to minimize leakage. So if you would please maximally move the macro definitions inside the module creation macro, that'd be great. Against which file version should I do the patch? Also: might take a moment. I'm a bit busy at the moment. I really don't like how translate-cl was changed. I strongly prefer: (define (translate-cl x) over: (define translate-cl ... (lambda (x) ... )) because it's MUCH easier in the first format to determine that this is a procedure that accepts exactly one parameter. Up, I just noticed that I forgot to add a type declaration here. But that should do the trick. Otherwise I understand that it might be a little harder to read. But I'd claim it's not much harder. And it might be worth the effort. See: First my definition for reference: (: translate-cl (* -- *)) (define translate-cl (let ((qq (string-symbol +++CL-QUASIQUOTE-abbreviation+++)) (uq (string-symbol +++CL-UNQUOTE-abbreviation+++)) (us (string-symbol +++CL-UNQUOTE-SPLICING-abbreviation+++))) (lambda (x) (if common-lisp (case x ((quasiquote) qq) ((unquote) uq) ((unquote-splicing) us) (else x)) x Also, the patched version will calculate 3 values on every entry; No, it does not compute any value upon entry. To the contrary, all those three bindings are computed just once at definition time. That's why I lifted them from the procedures body. the case should compute and return ONLY what it needs to compute. I presume that this isn't working: '+++CL-QUASIQUOTE-abbreviation+++ but you could replace *just* that with this format, yes?: (string-symbol +++CL-QUASIQUOTE-abbreviation+++) Yes, I could. But THIS would be one computation for each invocation (of the matching case here). Now this is rather cheap: a hash table lookup per quasiquote/unquote/unquote-splicing which in turn are rare. Why all the redefines from body to read-body? We normally use the same name as per the grammar. RScheme idiosyncratic: `body` is already a bound elsewhere within some code required com compile this code. Hence RScheme complains about the semantic error and that redefinition would break things. The only reasonable way I saw was to change the name to avoid the conflict. However by re-considering the case now I understand that the desire to keep `body` there literally to match the grammar. In that case we should macro-define body into read-body for RScheme only. We could do that if it's important to port to rscheme, I just want to know why before making the change. I presume you had a reason; if so, we need to document why this is an exception to the naming convention. Basically, just add a comment at the definition of read-body to explain why the naming convention is NOT being followed. Could you resend the patch, per those comments? Overall this looks really promising. As I said, busy by now. Maybe next week if things go well. Best Regards /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] initial support for rscheme
The attached diff makes the whole thing compile under rscheme too (and run some simple tests). No changes where made, which where not strictly necessary to that end. I'm sure you'll take issues with the positioning of cond-expand'ed stuff. I tried for now to keep the compatibility layer before the actual module. But that might leak definitions (like the rudimentary guard implementation) outside, which would have to be avoided. For this to we would have to move the whole section into the body of `readable-kernel-module-contents`, right? Best Regards /Jörg --- kernel.scm.orig 2013-11-21 12:19:00.0 +0100 +++ kernel.scm 2013-11-21 12:20:03.0 +0100 @@ -176,6 +176,97 @@ (define-module (readable kernel))) (else )) +; Chicken compatible type annotations. Ignored on other platforms. +(cond-expand + (chicken + (define-type :reader-proc: (input-port - *)) + (define-type :reader-token: (pair symbol *)) + (define-type :reader-indent-token: (list string *)) + (define-syntax no-values (syntax-rules () ((_) (void + ) + (rscheme + (define-macro (: . x) #f) + (define-macro (no-values) (values)) + ) + (else + (define-syntax : (syntax-rules () ((_ . rest) #f))) + (define-syntax no-values (syntax-rules () ((_) (if #f #t + )) + +; Implementation specific extension to flush output on ports. +(cond-expand + (guile ; Don't use define-syntax, that doesn't work on all guiles + (define (flush-output-port port) ; this is the only format we need. +(force-output port))) + (chicken + (define-syntax flush-output-port +(syntax-rules () ((_ port) (flush-output port) + (else )) + +; Special cases for those Scheme implementations which do that not +; support define-syntax. +; Note that guile is a large special case further down. + +(cond-expand + (rscheme + + (define-macro (readable-kernel-module-contents exports . body) +`(begin ;; (export ,@exports) + ,@body)) + + (define-macro (let-splitter (full first-value second-value) expr . body) +`(let* ((,full ,expr) + (,first-value (car ,full)) + (,second-value (cadr ,full))) + . ,body)) + ) + (else +; assume R5RS with define-syntax + +; On R6RS, and other Scheme's, module contents must +; be entirely inside a top-level module structure. +; Use module-contents to support that. On Schemes +; where module declarations are separate top-level +; expressions, we expect module-contents to transform +; to a simple (begin ...), and possibly include +; whatever declares exported stuff on that Scheme. +(define-syntax readable-kernel-module-contents + (syntax-rules () +((readable-kernel-module-contents exports body ...) + (begin body ... + ; There is no standard Scheme mechanism to unread multiple characters. + ; Therefore, the key productions and some of their supporting procedures + ; return both the information on what ended their reading process, + ; as well the actual value (if any) they read before whatever stopped them. + ; That way, procedures can process the value as read, and then pass on + ; the ending information to whatever needs it next. This approach, + ; which we call a non-tokenizing implementation, implements a tokenizer + ; via procedure calls instead of needing a separate tokenizer. + ; The ending information can be: + ; - stopper - this is returned by productions etc. that do NOT + ; read past the of a line (outside of paired characters and strings). + ; It is 'normal if it ended normally (e.g., at end of line); else it's + ; 'sublist-marker ($), 'group-split-marker (\\), 'collecting (*), + ; 'collecting-end (*), 'scomment (special comments like #|...|#), or + ; 'abbrevw (initial abbreviation with whitespace after it). + ; - new-indent - this is returned by productions etc. that DO read + ; past the end of a line. Such productions typically read the + ; next line's indent to determine if they should return. + ; If they should, they return the new indent so callers can + ; determine what to do next. A * should return even though its + ; visible indent level is length 0; we handle this by prepending + ; all normal indents with ^, and * generates a length-0 indent + ; (which is thus shorter than even an indent of 0 characters). + + (define-syntax let-splitter +(syntax-rules () + ((let-splitter (full first-value second-value) expr body ...) +(let* ((full expr) + (first-value (car full)) + (second-value (cadr full))) + body ... + )) + (cond-expand ; - ; Guile Compatibility @@ -243,10 +334,6 @@ (debug-set! stack 50) (no-values)) -; Implementation specific extension to flush output on ports. -(define (flush-output-port port) ; this is the only format we need. - (force-output port)) -
Re: [Readable-discuss] A road block: #:
Am 19.11.2013 05:38, schrieb David A. Wheeler: Am 18.11.2013 15:25, schrieb David A. Wheeler: On Mon, 18 Nov 2013 13:23:32 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: In a first attempt to feed the source to some other Scheme I went ahead and sent it to the rscheme compiler. Doesn't work. It has the same problem as Guile: it will refuse to read certain #sharp syntax. Okay, the source code no longer has #:. The result is extremely magical guile code, to work around some wonkiness in old versions of guile, but the magic is explained in comments. Great if this works in guile, rscheme reads it too. I'll be able to make progress. However I have a problem with another change: while all the Scheme's I know process nested cond-expand forms I recall that srfi-0 explicit does not requites this to be the case and suggest to avoid such use. Should be have these nested cond-expand's? Also: often different Scheme's can share different code parts. Enforcing a single cond-expand with nested cond-expands is not only against srfi-10; I can foresee how this will complicate the code and require quite some repetition and confusing logic in those conditions the cond-expand's dispatch on. Let alone that alternatives, which belong logically together are spread around in the file. That's a nightmare to maintain. Hence: I'd prefer to cluster all cond-expands at the beginning, but have one cond-expand per dispatch reason. Comments? Best Regards /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] noop patch - add type information
Am 17.11.2013 23:38, schrieb David A. Wheeler: On Sun, 17 Nov 2013 21:31:34 +0100, Jörg F. Wittenberger: In an attempt to better understand and document the source code I added type annotations (using the chicken's syntax and using chicken to verify it). I like this idea. In a few places this patch changes return values to intentionally return (values)... which is also okay by me. Unless anyone complains soon (Alan?), I plan to add it. It might be a bad idea to return no values instead of some undefined. Not sure, but I'd believe that notably chicken would do worse on returning no values instead of the fake value it returns for undefined returns. Also the patch introduces warnings that way. But nevertheless, I think the documentation it serves makes it worth. -- 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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
Am 17.11.2013 22:17, schrieb David A. Wheeler: On Sun, 17 Nov 2013 15:13:09 -0500, John Cowan co...@mercury.ccil.org wrote: I don't see any obvious way to do so, except with a weak-keyed hash table mapping ports to values. Unfortunately, weak-keyed hash tables are non-portable in the nature of things. I know. I'm currently thinking of implementing these settings as straight-up hash tables that map from ports to values. Those are, at least, efficient to look up, even if there are many ports. Ideally they'd be weak references, but I suspect most implementations don't constantly create new ports and pass them to readable. Well, BALL does. It finds many, many small expressions withing XML attributes when it produces wep pages. Those little scripts are feed to the reader. And if they do, they'll just slowly increase memory use.. not hugely. At least I would *not* bet a single cent on your slowly prediction here. There is a gimmick we could use. We could create a reset port function that *REMOVES* the entry from the hashtable. Then, on next use, it'd recreate the entries. That would be a clean interface, but work efficiently in a portable way. That would mean that systems would need to reset ports if they create huge numbers of them. Sadly, I don't see how to deal with that cleanly without weak references. I'm still not convinced. So far I did not understand why does this have to be port-specific in the first place. Maybe that would be the killer argument. Maybe not: at least in my case, I'd be *happy* to have a way to compile-time the feature away eventually, since I know these settings will not change. /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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] noop patch - add type information
Am 18.11.2013 10:38, schrieb Jörg F. Wittenberger: Am 17.11.2013 23:38, schrieb David A. Wheeler: On Sun, 17 Nov 2013 21:31:34 +0100, Jörg F. Wittenberger: In an attempt to better understand and document the source code I added type annotations (using the chicken's syntax and using chicken to verify it). I like this idea. In a few places this patch changes return values to intentionally return (values)... which is also okay by me. Unless anyone complains soon (Alan?), I plan to add it. It might be a bad idea to return no values instead of some undefined. Not sure, but I'd believe that notably chicken would do worse on returning no values instead of the fake value it returns for undefined returns. Also the patch introduces warnings that way. Attached a slightly better version of the add types patch. This one replaces (values) with a (no-values) syntax from the compatibility layer and has those procedures, which used to return no values or undefined values type-annotated as returning undefined. --- kernel.scm.orig 2013-11-17 21:23:38.0 +0100 +++ kernel.scm 2013-11-18 12:04:32.0 +0100 @@ -176,6 +176,19 @@ (define-module (readable kernel))) (else )) +; Chicken compatible type annotations. Ignored on other platforms. +(cond-expand + (chicken + (define-type :reader-proc: (input-port - *)) + (define-type :reader-token: (pair symbol *)) + (define-type :reader-indent-token: (list string *)) + (define-syntax no-values (syntax-rules () ((_) (void + ) + (else + (define-syntax : (syntax-rules () ((_ . rest) #f))) + (define-syntax no-values (syntax-rules () ((_) (if #f #t + )) + ; Implementation specific extension to flush output on ports. (cond-expand (guile ; Don't use define-syntax, that doesn't work on all guiles @@ -237,7 +250,7 @@ (define (init-sweet) ; Default guile stack size is FAR too small (debug-set! stack 50) - (values)) + (no-values)) ; Guile was the original development environment, so the algorithm ; practically acts as if it is in Guile. @@ -310,7 +323,7 @@ (define (setup-primitive-load) (cond (primitive-load-replaced - (values)) + (no-values)) (else (module-set! (resolve-module '(guile)) 'primitive-load (lambda (filename) @@ -463,7 +476,7 @@ (begin body ... ; A do-nothing. -(define (init-sweet) (values)) +(define (init-sweet) (no-values)) ; We use my-* procedures so that the ; port automatically keeps track of source position. @@ -594,9 +607,11 @@ (define keyword-syntax (make-parameter #f)) ; Returns a true value (not necessarily #t) + (: char-line-ending? (* -- boolean)) (define (char-line-ending? char) (memv char line-ending-chars)) ; Create own version, in case underlying implementation omits some. + (: my-char-whitespace? (char -- boolean)) (define (my-char-whitespace? c) (or (char-whitespace? c) (memv c whitespace-chars))) @@ -605,16 +620,18 @@ ; guile use annoying (EOF won't be correctly detected) due to a guile bug ; (in guile before version 2.0.8, peek-char incorrectly ; *consumes* EOF instead of just peeking). + (: consume-end-of-line (input-port - *)) (define (consume-end-of-line port) (let ((c (my-peek-char port))) (cond ((eqv? c carriage-return) - (my-read-char port) + (my-read-char port) (if (eqv? (my-peek-char port) linefeed) (my-read-char port))) ((eqv? c linefeed) (my-read-char port) + (: consume-to-eol (input-port - *)) ; FIXME (define (consume-to-eol port) ; Consume every non-eol character in the current line. ; End on EOF or end-of-line char. @@ -625,6 +642,7 @@ (my-read-char port) (consume-to-eol port) + (: consume-to-whitespace (input-port - (or eof null))) (define (consume-to-whitespace port) ; Consume to whitespace (let ((c (my-peek-char port))) @@ -648,6 +666,7 @@ (display \n))) data) + (: my-read-delimited-list (:reader-proc: char input-port - *)) (define (my-read-delimited-list my-read stop-char port) ; Read the inside of a list until its matching stop-char, returning list. ; stop-char needs to be closing paren, closing bracket, or closing brace. @@ -690,7 +709,9 @@ ; Read preservation, replacement, and mode setting ; - + (: default-scheme-read :reader-proc:) (define default-scheme-read read) + (: replace-read :reader-proc:) (define replace-read replace-read-with) (define (restore-traditional-read) (replace-read-with default-scheme-read)) @@ -708,8 +729,9 @@ (define (enable-sweet) (replace-read sweet-read)) - (define current-read-mode #f) + (define current-read-mode #f) ;; OBSOLETE? + (: set-read-mode deprecated) ; not yet, just
Re: [Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
Am 18.11.2013 10:56, schrieb Jörg F. Wittenberger: Am 17.11.2013 22:17, schrieb David A. Wheeler: On Sun, 17 Nov 2013 15:13:09 -0500, John Cowan co...@mercury.ccil.org wrote: There is a gimmick we could use. We could create a reset port function that *REMOVES* the entry from the hashtable. Then, on next use, it'd recreate the entries. That would be a clean interface, but work efficiently in a portable way. That would mean that systems would need to reset ports if they create huge numbers of them. Sadly, I don't see how to deal with that cleanly without weak references. So far I did not understand why does this have to be port-specific in the first place. Maybe that would be the killer argument. I wonder: the code already creates fake port object wrappers. Wouldn't this be the natural place to stick such per-port settings into??!! Instead of all those global or parameters, just _copy_ one vector of default values into the fake port, like this: (define (make-read f) (lambda args (let ((port (if (null? args) (current-input-port) (car args (f (list port (vector-copy default-sweet-read-parameters)) Objections? Something why this would not get the job done? (Maybe that would work better, if there was a port-fake-port procedure and a dispatch in the make-read depending on whether an already-upgraded port or a plain port was passed in.) /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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] A road block: #:
In a first attempt to feed the source to some other Scheme I went ahead and sent it to the rscheme compiler. Doesn't work. It has the same problem as Guile: it will refuse to read certain #sharp syntax. **HALT** error: scan-token:439: #\# cannot be followed by #\: Is there a way in Guile to split source in multiple files? Would it acceptable to split the compatibility section out of the main code for sweet/kernel? Otherwise I don't see how to proceed for rscheme and foresee the same problem around the corner for some other Schemes too. 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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] A road block: #:
Am 18.11.2013 15:25, schrieb David A. Wheeler: On Mon, 18 Nov 2013 13:23:32 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: In a first attempt to feed the source to some other Scheme I went ahead and sent it to the rscheme compiler. Doesn't work. It has the same problem as Guile: it will refuse to read certain #sharp syntax. **HALT** error: scan-token:439: #\# cannot be followed by #\: Is there a way in Guile to split source in multiple files? Would it acceptable to split the compatibility section out of the main code for sweet/kernel? Otherwise I don't see how to proceed for rscheme and foresee the same problem around the corner for some other Schemes too. I presume the problem is in this guile-specific code: (use-modules ((srfi srfi-69) #:select We can't replace #:select with (symbol-keyword 'select) unfortunately; guile won't recognize it. I suspect what we should do is right there temporarily have guile use prefix keyword notation (:select), using something like (read-set! keywords 'prefix), and then restore whatever was there before. Then other Schemes can read it. If that is possible, great! No comments so far on the possibility to put these things into platform-specific files? /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
Am 18.11.2013 15:28, schrieb David A. Wheeler: On Mon, 18 Nov 2013 12:19:21 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: I wonder: the code already creates fake port object wrappers. Wouldn't this be the natural place to stick such per-port settings into??!! That's not a bad idea. I was hoping for the fake ports to be a temporary shim for certain cases, I'm afraid I've seen so many cases, which could be solved by custom port refinements, that the only thing which is badly missing is a standard way to define custom ports. :-/ Just I'm short on any proposal to do just that. It's about as simple as coming up with the srfi for object oriented extensions to Scheme. A can of worms. not something we end up using everywhere, but I think you're right that it's plausible. So if nobody objects. ... ?? /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Portability tweaks to kernel.scm (our Scheme implementation)
Am 17.11.2013 03:02, schrieb David A. Wheeler: I've tweaked the readable code to address some of the portability issues that Joerg Wittenberger noted. It should now be easier to port the code to other Schemes. The main code now uses R6RS/R7RS exception syntax and makes a call to a special init-sweet. The guile-specific code now implements R6RS/R7RS exception syntax, and its version of init-sweet calls the guile-specific debug-set!. That eliminates those guile-specific portions from the main code line. Implementations that support R6RS/R7RS exception syntax and need no special initialization should now work unchanged. Joerg: I hope that helps. This version works on guile. Does it? Then either guile has an (eq? eq eq?) evaluate to true or the exception handler was never invoked. That is: I would guess. My problem with this corner of the code is that I don't understand what it is supposed to do. (define (t-expr-catch port) (init-sweet) (guard (exception ((eq exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) 1. I would believe that this ought to be ((eq? exception 'readable) ...) Note thee missing question mark. 2. The exception handler will somehow catch all exceptions from read-error, correct? Then it handles them by ignoring the error input and some following text, still correct? Somehow the error will only appear on the error port (which is something I'd have to handle somehow special anyway, since when I'm running this in a server, it will only garble my error log file. But also the guard implementation itself looks suspicious to me: (define-syntax guard (syntax-rules () ((guard (exception ((eq exception2 value) run-when-true ...)) body) (catch value (lambda () body) (lambda (key . args) run-when-true ...) Besides that it again relies on my assumption that guile must have eq as alias to eq?, I don't see where the identifier exception2 becomes bound. /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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
Am 17.11.2013 00:59, schrieb David A. Wheeler: On 16 Nov 2013 22:16:27 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: 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? Depends on your notion of significance. Attached a patch. --- kernel.scm.orig 2013-11-17 14:29:29.0 +0100 +++ kernel.scm 2013-11-17 14:38:13.0 +0100 @@ -544,7 +544,7 @@ ; so let's start with #f (case-sensitive). ; This doesn't affect character names; as an extension, ; We always accept arbitrary case for them, e.g., #\newline or #\NEWLINE. - (define is-foldcase #f) + (define is-foldcase (make-parameter #f)) ; special tag to denote comment return from hash-processing @@ -579,10 +579,10 @@ (define whitespace-chars whitespace-chars-ascii) ; If #t, handle some constructs so we can read and print as Common Lisp. - (define common-lisp #f) + (define common-lisp (make-parameter #f)) ; If #t, return |...| symbols as-is, including the vertical bars. - (define literal-barred-symbol #f) + (define literal-barred-symbol (make-parameter #f)) ; Returns a true value (not necessarily #t) (define (char-line-ending? char) (memv char line-ending-chars)) @@ -705,13 +705,13 @@ ; TODO: Should be per-port (cond ((eq? mode 'common-lisp) -(set! common-lisp #t) #t) +(common-lisp #t) #t) ((eq? mode 'literal-barred-symbol) -(set! literal-barred-symbol #t) #t) +(literal-barred-symbol #t) #t) ((eq? mode 'fold-case) -(set! is-foldcase #t) #t) +(is-foldcase #t) #t) ((eq? mode 'no-fold-case) -(set! is-foldcase #f) #t) +(is-foldcase #f) #t) (else (display Warning: Unknown mode) #f))) ; - @@ -872,7 +872,7 @@ ; is-foldcase configuration value when processing symbols. ; TODO: Should be port-specific (define (fold-case-maybe port s) -(if is-foldcase +(if (is-foldcase) (my-string-foldcase s) s)) @@ -886,9 +886,9 @@ ((string-ci=? dir curly-infix) (replace-read curly-infix-read)) ((string-ci=? dir fold-case) -(set! is-foldcase #t)) +(is-foldcase #t)) ((string-ci=? dir no-fold-case) -(set! is-foldcase #f)) +(is-foldcase #f)) (else (display Warning: Unknown process directive ; Consume characters until !# @@ -1003,7 +1003,7 @@ (else ; Try out different readers until we find a match. (my-read-char port) (or -(and common-lisp +(and (common-lisp) (parse-cl no-indent-read c port)) (parse-hash no-indent-read c port) (parse-default no-indent-read c port) @@ -,7 +,7 @@ ; Translate x to Common Lisp representation if we're printing CL. ; Basically we use a very unusual representation, and then translate it back (define (translate-cl x) -(if common-lisp +(if (common-lisp) (case x ((quasiquote) '+++CL-QUASIQUOTE-abbreviation+++) ((unquote) '+++CL-UNQUOTE-abbreviation+++) @@ -1228,7 +1228,7 @@ (define (get-barred-symbol port) (my-read-char port) ; Consume the initial vertical bar. (string-symbol (list-string - (if literal-barred-symbol + (if (literal-barred-symbol) (cons #\| (read-literal-symbol port)) (read-symbol-elements port) -- 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=63469471iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Fwd: Re: Supporting SRFI-110 in chicken (Joerg Wittenberger)
Am 17.11.2013 21:13, schrieb John Cowan: David A. Wheeler scripsit: Hmm. R7RS has make-parameter, as does SRFI-39. But guile 1.6 has neither, and I don't know how widely-available these really are. The implementation given in R7RS is pretty portable, but should *not* be used on Schemes with their own implementations, because it may not be thread safe. Note that R7RS parameters, unlike SRFI 39 ones, are not mutable (as opposed to rebindable): I'm not sure that I understand this. (My weak English.) Let's try by example: (define x (make-parameter #f)) Does this: (x #t) count as mutation in this respect or is it the way you do a rebind? /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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] noop patch - add type information
In an attempt to better understand and document the source code I added type annotations (using the chicken's syntax and using chicken to verify it). So far I'm only through to the read-related procedures. But it's so much, I solicit comments from those who know the code. At least it still compiles and works, even using chickens -strict-types mode (which, in between when there was one badly broken type declaration, did already result in non-working code --- supporting my understanding that chicken's -strict-types mode is not a noop.). --- kernel.scm.orig 2013-11-17 21:23:38.0 +0100 +++ kernel.scm 2013-11-17 21:23:52.0 +0100 @@ -176,6 +176,17 @@ (define-module (readable kernel))) (else )) +; Chicken compatible type annotations. Ignored on other platforms. +(cond-expand + (chicken + (define-type :reader-proc: (input-port - *)) + (define-type :reader-token: (pair symbol *)) + (define-type :reader-indent-token: (list string *)) + ) + (else + (define-syntax : (syntax-rules ((_ . rest) #f))) + )) + ; Implementation specific extension to flush output on ports. (cond-expand (guile ; Don't use define-syntax, that doesn't work on all guiles @@ -594,9 +605,11 @@ (define keyword-syntax (make-parameter #f)) ; Returns a true value (not necessarily #t) + (: char-line-ending? (* -- boolean)) (define (char-line-ending? char) (memv char line-ending-chars)) ; Create own version, in case underlying implementation omits some. + (: my-char-whitespace? (char -- boolean)) (define (my-char-whitespace? c) (or (char-whitespace? c) (memv c whitespace-chars))) @@ -605,16 +618,18 @@ ; guile use annoying (EOF won't be correctly detected) due to a guile bug ; (in guile before version 2.0.8, peek-char incorrectly ; *consumes* EOF instead of just peeking). + (: consume-end-of-line (input-port - *)) (define (consume-end-of-line port) (let ((c (my-peek-char port))) (cond ((eqv? c carriage-return) - (my-read-char port) + (my-read-char port) (if (eqv? (my-peek-char port) linefeed) (my-read-char port))) ((eqv? c linefeed) (my-read-char port) + (: consume-to-eol (input-port - *)) ; FIXME (define (consume-to-eol port) ; Consume every non-eol character in the current line. ; End on EOF or end-of-line char. @@ -625,6 +640,7 @@ (my-read-char port) (consume-to-eol port) + (: consume-to-whitespace (input-port - (or eof null))) (define (consume-to-whitespace port) ; Consume to whitespace (let ((c (my-peek-char port))) @@ -648,6 +664,7 @@ (display \n))) data) + (: my-read-delimited-list (:reader-proc: char input-port - *)) (define (my-read-delimited-list my-read stop-char port) ; Read the inside of a list until its matching stop-char, returning list. ; stop-char needs to be closing paren, closing bracket, or closing brace. @@ -690,7 +707,9 @@ ; Read preservation, replacement, and mode setting ; - + (: default-scheme-read :reader-proc:) (define default-scheme-read read) + (: replace-read :reader-proc:) (define replace-read replace-read-with) (define (restore-traditional-read) (replace-read-with default-scheme-read)) @@ -708,8 +727,9 @@ (define (enable-sweet) (replace-read sweet-read)) - (define current-read-mode #f) + (define current-read-mode #f) ;; OBSOLETE? + (: set-read-mode deprecated) ; not yet, just as a marker for the open questions (define (set-read-mode mode port) ; TODO: Should be per-port (cond @@ -764,17 +784,20 @@ #\ #\;) ; Could add #\# or #\| whitespace-chars)) + (: consume-whitespace (input-port -)) (define (consume-whitespace port) (let ((char (my-peek-char port))) (cond -((eof-object? char)) +((eof-object? char) (values)) ((eqv? char #\;) (consume-to-eol port) (consume-whitespace port)) ((my-char-whitespace? char) (my-read-char port) - (consume-whitespace port) + (consume-whitespace port)) + (else (values) + (: read-until-delim (input-port (list-of char) - (list-of char))) (define (read-until-delim port delims) ; Read characters until eof or a character in delims is seen. ; Do not consume the eof or delimiter. @@ -785,6 +808,7 @@ ((memv c delims) '()) (else (my-read-char port) (cons c (read-until-delim port delims)) + (: read-error (* - . *)) (define (read-error message) (display Error: (current-error-port)) (display message (current-error-port)) @@ -795,20 +819,30 @@ ; Return the number by reading from port, and prepending starting-lyst. ; Returns #f if it's not a number. + (: read-number (input-port (list-of char) - (or number
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=63469471iu=/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 14.11.2013 21:02, schrieb David A. Wheeler: I said: If you could help us integrate the rest of your changes into the code, that'd be great. Sure. Which one are missing by now? Here's what I think is missing. I'm hoping you'll join the mailing list soon, and that we can discuss these publicly. These shouldn't be hard, but we need to *not* bust guile support. In fact, we include support for some fairly old versions of guile, because that's what some people have. Sure! especially now that GNUmake supports guile too. In fact I'll have to install it on my machine one day. NOTE: First patch hunk - we've switched to flush-output-port, but we need to address throw vs. raise. --- srfi-110.orig.scm 2013-11-07 14:13:43.0 +0100 +++ srfi-110.test.scm 2013-11-13 11:30:31.0 +0100 @@ -2009,13 +2020,19 @@ ; Call on sweet-expression reader - use guile's nonstandard catch/throw ; so that errors will force a restart. (define (t-expr-catch port) - +#| ; Default guile stack size is FAR too small (debug-set! stack 50) (catch 'readable (lambda () (t-expr port)) - (lambda (key . args) (read-to-unindented-line port) (t-expr-catch port + (lambda (key . args) (read-to-unindented-line port) (t-expr-catch port))) +|# + (guard + (ex ((eq? ex 'readable) (read-to-unindented-line port) (t-expr-catch port)) + (else (raise ex))) + (t-expr port)) +) ; - ; Write routines 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? You comment about old guile refers to the use of guard/raise at all, doesn't it? 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? 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. @@ -173,7 +173,17 @@ ; define the module ; this ensures that the user's module does not get contaminated with ; our compatibility procedures/macros -(define-module (readable kernel +(define-module (readable kernel))) + (chicken + (define string-keyword + (let ((kwprefix (string (integer-char 0 + (lambda (tok) + (##sys#intern-symbol + (if (eq? 0 (##sys#size tok)) + : + (##sys#string-append kwprefix tok)) + ) + (else )) (cond-expand ; - ; Guile Compatibility @@ -1268,10 +1280,11 @@ ((char=? c #\| ) ; Read |...| symbol (like Common Lisp and R7RS draft 9) (get-barred-symbol port)) - (#t ; Nothing else. Must be a symbol start. - (string-symbol (fold-case-maybe port - (list-string - (read-until-delim port neoteric-delimiters))) + (else ; Nothing else. Must be a symbol start. + (let ((s (fold-case-maybe port (list-string (read-until-delim port neoteric-delimiters) + (if (eq? (string-ref s (sub1 (string-length s))) #\:) + (string-keyword (substring s 0 (sub1 (string-length s + (string-symbol s)) ; - ; Curly Infix So how would this work for guile? Does it have a string-keyword? Or was is a symbol-keyword? /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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
