Re: [Readable-discuss] Discussion: Should leading "." in sweet-expressions have wisp semantics?
Am 27.11.2014 um 20:03 schrieb Arne Babenhauserheide: > Am Donnerstag, 27. November 2014, 08:47:49 schrieb David A. Wheeler: >>> However within "normal" s-expressions or neotheric expressions I'd have >> second thoughts. How would this be parsed?: >> >>> foo bar >>> . aaa . bbb ccc >> >> I agree, that should be an error. It doesn't really make any sense to me >> either. I expect this would continue to be ok: >> >> aaa bbb . ccc >> => >> (aaa bbb . ccc) >> >> And the following would still be an error: >> aaa bbb . ccc ddd +1 > > That’s also what wisp does: The leading dot is interpreted as > continuation if it’s the first character in a line in > indentation-sensitive code. > > It would be cool to see sweet and wisp move closer together here! +1 How does wisp deal with these? 1.: foo bar . aaa bbb ccc . ddd eee 2.: foo bar . aaa bbb . ccc . ddd eee signature.asc Description: OpenPGP digital signature -- 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=157005751&iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
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=157005751&iu=/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=157005751&iu=/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.
On May 9 2014, John Cowan 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.
>
>I think that's a killer.
One could also argue that there are three tokens effecting whitespace
handling: (, { and {*
{* is only valid in sweet as <* is - as required by spec. It shifts to 0
indent.
{ shifts to curly. ( to noteric.
I'd say this is a fairly consistent and clear set of rules.
Frankly, I'd expect a dev to be a quite advanced one until the need to write
{* x -}
and want an infix operator "x" applied to * and -. By that time the dev
should easily see that in whitespace mode {* is a marker and not the begin
of a curly expr and figure a space would help. After all neoteric rule have
taught the lesses to look twice for spaces.
>
>Frankly, this is what CDATA sections were made for. Wrap your Lisp
>code in "" brackets, and < is no longer magic.
>(Note that > is never magic, though there is an escape for it anyway.)
>
>
--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• 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
Re: [Readable-discuss] Damage done.
Sure CDATA could solve the problem. So could encoding as < .
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
> wrote:
>> I think that's a killer.
>>
>> Frankly, this is what CDATA sections were made for. Wrap your Lisp
>> code in "" 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: • 3 signs your SCM is hindering your productivity •
> Requirements for releasing software faster • 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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• 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] Unused procedures
BTW: I'm getting warnings about unused procedures: appende represent-as-brace-suffix? should those go? -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • 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 gr
Re: [Readable-discuss] I've got a problem with the readability.
Am 08.05.2014 04:00, schrieb David A. Wheeler:
> I exclaimed:
>>> Hmm. Technically I don't think "<*" is legal at all in XML.
> On Wed, 7 May 2014 20:05:52 -0400, John Cowan
> replied:
>> It's illegal in the surface syntax. To express it in element
>> content or an attribute value, you must write "<*".
> Yes. Which means you could write it, and then use some preprocessor to
> transform it into valid XML (or use a tweaked XML processor that interpreted
> it specially).
Yes, precisely. That's the problem. I can't change all the xml parses
a user might want to throw at the code. Hence tweaking the XML
processor is no option.
What I can do right now using the sweet parser as it is, is simply write
let <* a 1 *> {a + a}
And get a 2 back.
That's how it ends up in the file according to XML spec. No way
around. Developer will see it.
Ugly, hard to type, hence bad.
XML parser will resolve < char reference.
What I'd like to have in the XML encoded file would be - taking { } - as
grouping:
let {* a 1 *} {a + a}
This overloads the meaning of #\{ in sweet, thus might not be
desirable. In return it minimizes the amount of special characters.
And it looks almost like
let <* a 1 *> {a + a}
though no XML quoting will be superimposed.
Since any character already handled special by the reader would also
fulfill the desire to not allocate more special characters, one could
thing for instance about #\# instead of the braces:
let #* a 1 *# {a + a}
Sorry, but I would take that as something like a block comment, maybe a
special block comment? maybe some compiler hint magic, that sort of
thing. YMMV.
The the { } pair however is in SRFI-110 already used to "modify the
indentation rules and position of implicit parenthesis" so to speak.
Having {* and *} do the other kind of the same seems not that bad to me.
Please excuse my ignorance, ANTLR sweet.g is beyond my capacity for a
timely reply.
The CL implementation looks at the first glance like an almost
mechanical translation wrt. the Scheme code I read before.
If not the sweet.g, I don't see how it could come that dispatching on
#\{ would be hard to change. Characters are read one-by-one using
my-read/peak-char, aren't they?
>
> --- David A> Wheeler
>
> --
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • 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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• 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
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:
>>
>> !
>> ! !
>>
>> 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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• 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: <* >*.
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] New Release?
Am 13.02.2014 14:18, schrieb Alan Manuel Gloria: > On 2/13/14, "Jörg F. Wittenberger" wrote: >> Am 13.02.2014 09:50, schrieb Alan Manuel Gloria: >>> I'm kinda sorta vaguely planning on a Scheme implementation which has >>> STM at its core (basically, all non-transactional mutations are >>> implicitly considered to be inside tiny transactions containing only >>> that mutation). >> Have you seen http://ball.askemos.org ? > Err. not really, and it's a bit more large-scale than what I had in mind. Yes, it certainly is. Nevertheless the idea is, that the fault-tolerant, replicated state is some kind of STM. > >> Your idea reminds me so much to our reasoning. Just because our >> transactional memory was known to be horribly slow, we decided to have >> two complementary Scheme-alike languages: one without any side effects >> (no effects to be handled in STM, zero overhead) and one sub-language >> having only the effects. ((Though to distinguish them we chose to >> express the latter in "long-wielded-s-expressions" a.k.a. "XML".)) >> >> I'm pretty interested in your plans and progess. Please keep me posted. > It strikes me that the separation of purity and impurity here is > almost precisely what Haskell does with the separation of the "actual" > language and the IO data type. In a way yes. > In any case, my (vague) plan is a relatively simple R7RS compiler, > with everything as a transaction (both mutations and reads), and the > possibility to combine multiple transactions into a larger > transaction. I/O is a bit mind-bending, so I'll go with "not a > transaction, and will throw an error if you put in a transaction," > which is the default handling in pretty much every STM implementation > I've seen. Again: please keep me postet. Sounds interesting. /Jörg -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] New Release?
Am 13.02.2014 09:50, schrieb Alan Manuel Gloria: > I'm kinda sorta vaguely planning on a Scheme implementation which has > STM at its core (basically, all non-transactional mutations are > implicitly considered to be inside tiny transactions containing only > that mutation). Have you seen http://ball.askemos.org ? Your idea reminds me so much to our reasoning. Just because our transactional memory was known to be horribly slow, we decided to have two complementary Scheme-alike languages: one without any side effects (no effects to be handled in STM, zero overhead) and one sub-language having only the effects. ((Though to distinguish them we chose to express the latter in "long-wielded-s-expressions" a.k.a. "XML".)) I'm pretty interested in your plans and progess. Please keep me posted. /Jörg >If ever, it will of course have SRFI-105 by default > and SRFI-110 on #!sweet. > -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk ___ 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=111408631&iu=/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=111408631&iu=/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 K&R 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=84349351&iu=/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=84349351&iu=/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" >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=63431311&iu=/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 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=63431311&iu=/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=63431311&iu=/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->k
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" >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=63431311&iu=/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 22.11.2013 04:45, schrieb David A. Wheeler: > On Thu, 21 Nov 2013 12:29:58 +0100, "Jörg F. Wittenberger" > 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=63431311&iu=/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-out
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" >>> 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=63431311&iu=/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" >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 port"s 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=63431311&iu=/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" >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=63431311&iu=/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=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] 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 >> 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=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] 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))
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 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=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] noop patch - add type information
Am 18.11.2013 04:38, schrieb John Cowan: > David A. Wheeler scripsit: > >> Yes, but if that gets back to the REPL it may do something funny. By >> definition that is undefined. > By definition it's an undefined *value*. Which is the actual problem: the definition. IMHO there should be no undefined *value* as such. It should be just undefined what's being returned. If - for some reason - some fake value need to be there to satisfy some other condition, so be it. But Scheme would IMHO be better off along the default Racket way. >In all the Schemes I have, it > returns either an undefined-value object (which the REPL suppresses the > printing of) or some random object such as #t or #f. The exception is > Racket, in which it is a syntax error: there is no guarantee that the > default Racket language is Scheme conformant, though. > >>> But I can live with it. >> Yes, but I want to make this *more* portable not *less*. >> >> Maybe we should define our own "no-value" value, >> and use a macro to define it. > Why a macro? It can be just a function (as it is in Chicken, named `void`) > or even just a global variable. > Because a macro would make things Racket compatible, a value would just re-enforce the questionable definition. I'll deal with that. David, should I just keep patching or do you have a current snapshot of the accepted patches so far for me? /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] 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=63469471&iu=/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) ->
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=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] set-read-mode
Am 17.11.2013 16:04, schrieb David A. Wheeler: > On Sun, 17 Nov 2013 15:17:18 +0100, "Jörg F. Wittenberger" >wrote: >> When looking at set-read-mode I'm not sure it integrates well. >> >> It claims that it should support per-port settings. Does not know how >> to do this and me neither. >> >> However using parameters lends itself to per-port semantics. >> >> All we'd have to export those parameters and get to per-port settings by >> means of parameterize. >> >> Ho about? > We really should support per-port settings. I appreciate the > parameter patch, but making them parameters is kind of a workaround. > > I find no officially-standard way to compare ports. > However, I'm guessing that in practice "eq?" should be able > to determine if two ports are the same or not. If so, > we could create a hashtable of port => portsettings, > and then tweak your parameter patch to use that. > > Anyone else have comments? > My current believe is, that parameters would actually be the best and most standard compliant way to handle this. Though this might come from a missing understanding about the intended semantics. Using parameters, once could easily have something like (define (sweet-cl-read . args) (parameterize ((common-lisp #t)) (apply sweet-read args))) and you are done. This should read from the port with common-lisp semantics. Though I'm not clear about those reader directives (which I would have loved to be ruled out of their mere existence right from the beginning an even before). If those would change the common-lisp value, then their effect would extend over the very next expression only instead from here to end of input from port. But how do those apply to "load"ed or "include"d code anyway? As to maintaining yet another table just to keep those values port-specific: I'd really not love that. It makes the code much more complex. Withing environments like mine, where there code runs on rather limited hardware, I'd love to know that it does not do so many extra lookup just to learn that (by my definition elsewhere) these values will not change anyway. I don't object to such port specific things in general. But I'd prefer them to be mere optional. Furthermore I'd pessimistic about the feasibility of the hash-table approach: How precisely would we determine when the port must/may be deleted from the hash table? SRFI-69 does not specify hash tables with weak references. Best Regards /Jörg -- DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] set-read-mode
When looking at set-read-mode I'm not sure it integrates well. It claims that it should support per-port settings. Does not know how to do this and me neither. However using parameters lends itself to per-port semantics. All we'd have to export those parameters and get to per-port settings by means of parameterize. Ho about? -- 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
[Readable-discuss] keyword support
Here a patch to be applied atop of the one introducing parameters for global. --- kernel.scm.orig 2013-11-17 15:00:41.0 +0100 +++ kernel.scm 2013-11-17 15:01:19.0 +0100 @@ -440,6 +440,9 @@ (define (type-of x) #f) (define (type? x) #f) + (define (string->keyword s) +(symbol->keyword (string->symbol s))) + ) ; - ; R5RS Compatibility @@ -584,6 +587,12 @@ ; If #t, return |...| symbols as-is, including the vertical bars. (define literal-barred-symbol (make-parameter #f)) + ; Case #f: no keywords case 'prefix keywords start with colon, case + ; 'suffix keywords end in colon, case 'hash keywords start with #: + ;; The latter is not yet implemented except for guile. + + (define keyword-syntax (make-parameter #f)) + ; Returns a true value (not necessarily #t) (define (char-line-ending? char) (memv char line-ending-chars)) @@ -712,6 +721,12 @@ (is-foldcase #t) #t) ((eq? mode 'no-fold-case) (is-foldcase #f) #t) + ((eq? mode 'keyword-style-hash) + (keyword-syntax 'hash)) + ((eq? mode 'keyword-style-prefix) + (keyword-syntax 'prefix)) + ((eq? mode 'keyword-style-suffix) + (keyword-syntax 'suffix)) (else (display "Warning: Unknown mode") #f))) ; - @@ -1315,10 +1330,21 @@ ((char=? c #\| ) ; Read |...| symbol (like Common Lisp and R7RS draft 9) (get-barred-symbol port)) - (else ; 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 or keyword start. + (let ((s (fold-case-maybe port (list->string (read-until-delim port neoteric-delimiters + (kws (keyword-syntax))) + (cond + ((or (eq? kws #f) + (eq? kws 'hash) + (< (string-length s) 2)) + (string->symbol s)) + ((and (eq? kws 'prefix) + (eq? (string-ref s 0) #\:)) + (string->keyword (substring s 1 (string-length s + ((and (eq? kws 'suffix) + (eq? (string-ref s (sub1 (string-length s))) #\:)) + (string->keyword (substring s 0 (sub1 (string-length s) + (else (string->symbol s))) ; - ; Curly Infix -- 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] Portability tweaks to kernel.scm (our Scheme implementation)
Am 17.11.2013 14:52, schrieb David A. Wheeler: > On Sun, 17 Nov 2013 14:19:37 +0100, "Jörg F. Wittenberger" >> 1. I would believe that this ought to be ((eq? exception 'readable) ...) >> Note thee missing question mark. > Whups. You're right, of course. I knew there was a reason for many eyes. :-). > I keep switching between Common Lisp and Scheme > on this project, so that slipped through. > > I've changed all the "(eq ...)" to "(eq? ...)" and pushed that to the repo. > >> My problem with this corner of the code is that I don't understand what >> it is supposed to do. > ... >> 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. > More or less. > We could let the exception escape out of the read routine entirely, > but since exceptions aren't even standard in R5RS, I suspect > a lot of programs aren't really ready for them. So the implementation > currently just whines and tries again. > > All syntax errors call "read-error", which sends > output to (current-error-port) and raises 'readable. > Procedure "t-expr-catch" uses a guard to catch 'readable; > if it catches it, it calls (read-to-unindented-line port) to clean out the > input, and then tail-calls t-expr-catch to try again. > Only procedures read-error and t-expr-catch actually invoke > exception handling, though the rest of the code is written > assuming that the exceptions are handled elsewhere. > > If you want to handle the error information specially, I suggest > temporarily changing the current-error-port. > If that won't work, let us know! I'd rather catch the exceptions elsewhere. (Which I do already. Such parser errors would result in a 500 something HTTP reply. Simply ignoring at the error port would be hard. I'd have to add yet another exception handler and after each request I'd have to check whether the error-port has anything and then generate an error reply. A lot of overhead just because of yet another parser. And if I was to simply ignore the error, then the code would continue. Given the (planned) context, where the code will produce a (possibly modified) copy of itself under circumstances, this could result in parts of the code simply missing. Too bad. > >> 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. > It does not. The "exception2" should match "exception" but the > code doesn't check for that. Ah, I see. Now. -- 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] 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 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=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] Portability tweaks to kernel.scm (our Scheme implementation)
Am 17.11.2013 14:19, schrieb "Jörg F. Wittenberger": 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. Forgot the diff. Appended. --- kernel.orig.scm 2013-11-17 13:45:50.0 +0100 +++ kernel.scm 2013-11-17 14:25:09.0 +0100 @@ -775,7 +775,6 @@ (display message (current-error-port)) (newline (current-error-port)) (flush-output-port (current-error-port)) -; Guile extension, but many Schemes have exceptions (raise 'readable) '()) @@ -2062,7 +2061,7 @@ (guard (exception -((eq exception 'readable) +((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr 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=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] 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=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 17.11.2013 00:27, schrieb David A. Wheeler: > On 16 Nov 2013 21:05:11 +0100, Jörg F. Wittenberger > wrote: >> 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. There is no special formatted comments. I't about all comments. What I'm doing, at least with the XML syntax tree is to transform it, I change parts of the tree. However afterwards I need to be able to feed it to the human to edit it, at which point I don't want the comments to be lost. I want to be able to do the same thing to the AST derived from Scheme source code. > 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, That would do it. > 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 :-). > Sure. /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] 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
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=63469471&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
