Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
Hmm. Generating code is reasonable of course. One problem with the shar approach is that common code will be copied into different separate files, and eventually not consistently maintained. I'd like to say one thing once as much as possible (for maintenance). A variation would be to create ONE shell script that can generate (to stdout) Scheme code for the variant identified in a parameter; it could cat the main code at the right time. Something like: = #!/bin/env sh # $1 is the type to generate. case $1 in GUILE) echo ... ;; *) echo ... ;; esac cat kernel.scm = A completely different approach is a cpp-like tool. I've cobbled together an awk implementation of cpp-like syntax so you can do this: #ifdef GUILE ... #elseifdef RSCHEME ... #else ... #endif Either one would mean that we only need to say something ONCE if it can be used in multiple circumstances. I *think* awk can be more portable. The nice thing with the separate-processors approach is that we can solicit just the bits we need to concatenate from the various Scheme islands. If we have one file that makes everything, it will eventually become a single large monster that no one likes to touch (assuming widespread usage of this particular implementation of SRFI-110, at least). Separate generators for each implementation-version we claim to support strikes as more maintainable in the long run. I don't expect a lot of code duplication, if we could have a good enough set of things I assume the compatibility layer can do. Oh, and source annotation is a er. The style used assumes Guile idioms. In Racket a reader is supposed to return syntax objects, which wrap a datum and the source location and top-level lexical environment. Syntax objects are either a datum+source loc, or a syntax-cons on syntax objects (or a syntax-vector or a syntax-whatever). It's theoretically possible to use a eq?-key hash table for attach-source-info (key is the datum, value is the source info), wrap sweet-read, and when sweet-read returns a datum, to convert the datum and its sub-datums to syntax objects, attaching the source info to each datum. Instead of exporting sweet-read directly, we just wrap it into an extra layer of (let () ..) that returns sweet-read and friends, then wraps the returned sweet-read into an actual sweet-read that makes the hash table and does the whatever whatever needed to turn them into syntax objects. The hash table does not need to be weak-keyed, since it lives only within the sweet-read invocation. Sincerely, AmkG -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
John Cowan dropped the following bad news: Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries can't be the result of a macro, neither as a whole nor in part. All you've done is trade off one set of portability breakers for another. I said: Ugh. In that case, maybe we should just drop the readable-kernel-module-contents macro altogether, and just write straight code with weird names to reduce possible namespace problems. We can include cond-expand guile magic so that it works as-is as a guile module. Alan: Any objections? On Fri, 6 Dec 2013 12:12:51 +0800, Alan Manuel Gloria almkg...@gmail.com wrote: None whatsoever. I think Jorg's proposal to make a file (the shar) that makes the output based on the detected Scheme implementation is good. We could even run the file multiple times to generate different outputs, one for each Scheme supported and detected. I propose this system: 1. We write as if we own the namespace. Select some suitable soup of features from R4RS through R7RS, and define it in comments well in the core implementation file. The core implementation file is then just a bunch of (define ...) forms, possibly with some hooks on options like CL mode or Scheme mode. 2. Write a bunch of shars, which take the original file and transform it to code that a particular Scheme implementation-version accepts. Basically, it just prepends and appends some additional code, probably just plain text, to the core implementation file. The shar can put the entire core implementation file within some sort of (define-library... ) form, if needed. 3. If a particular Scheme implementation-version supports parameters, then the CL mode option can be made into a parameter. If not, it can be a global instead. We document this in, say, a USAGE.Chicken or USAGE.Guile-1.8 or whatever file. For example, a standard R5RS shar would just wrap the implementation file in something like: #! /bin/sh IN=$1 OUT=$2 cat $OUT PREFIX (define (readable%is-cl-mode) readable%cl-mode) (define readable%cl-mode #f) (define readable%whatevers (let () PREFIX cat $IN $OUT cat $OUT SUFFIX (list sweet-read neoteric-read curly-read) ) ;let ); define readable%whatevers (define sweet-read (car readable%whatevers)) (define neoteric-read (cadr readable%whatevers)) (define curly-read (caddr readable%whatevers)) SUFFIX Hmm. Generating code is reasonable of course. One problem with the shar approach is that common code will be copied into different separate files, and eventually not consistently maintained. I'd like to say one thing once as much as possible (for maintenance). A variation would be to create ONE shell script that can generate (to stdout) Scheme code for the variant identified in a parameter; it could cat the main code at the right time. Something like: = #!/bin/env sh # $1 is the type to generate. case $1 in GUILE) echo ... ;; *) echo ... ;; esac cat kernel.scm = A completely different approach is a cpp-like tool. I've cobbled together an awk implementation of cpp-like syntax so you can do this: #ifdef GUILE ... #elseifdef RSCHEME ... #else ... #endif Either one would mean that we only need to say something ONCE if it can be used in multiple circumstances. --- David A. Wheeler -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
Am 27.11.2013 02:28, schrieb David A. Wheeler: I said: At the least, I could put things in different files, and then use cat to create files usable to different systems. On Tue, 26 Nov 2013 14:47:36 +0100, Jörg F. Wittenberger: Not too bad and idea. While it might not scale to whole programs, it's certainly a valid way to get things done for something the size of a srfi's implementation. Right. This thing is small. I don't see anything good for trivial preprocessing: * scmxlate appears too complex to get going. Probably. A few bullet point about my take on this. 1) Whatever we do here, it's not necessarily going to be used for real but merely to show how things would have to be processed in users build. 2) From (1) I conclude: the least amount of commonly available tools is the best. 3) When pre-processing LISP code, the best language for the job is actually LISP, since it has easily access to the structure of the code to be rewritten. Other languages are forced to go through axillary properties of the code. cpp, as you said, is a disaster for LISP and m4 is a disaster in itself. 4) Point (3) is mostly incompatible with (2). The only exception might be recent GNUmake. I did not yet have the time to check it out, but I read it would support guile. Maybe one could trick it into running a guile pre-process. 5) Coming back once more to my desire to have a Scheme reader which would allow to deliver a modified AST including comment nodes: such a beast could be used to write back-and-forth (round-trip-safe) code to code transformations. One could work with any flavor when porting to new implementations and easily roll the result back into the generic form. All this should need would be the generic base and a guile-as-in-gnumake specialized version. Let me add: I'm not entirely sold to (5) but I'd like to see how this would work in reality before I judge. * cpp is a disaster for Lisp (it wants to parse '...' as character constants) * m4 is easy to get wrong, and has too much functionality. I think I could create a simple #ifdef ... #elifdef... #else... #endif preprocessor in awk (which is in the POSIX standard) that would do the job. If I dug deep enough into the code I ever wrote, I guess I could come back with at least two such things in KR C. ;-) I'm not sure it's worth to write a special tool just for this special case. Then the whole thing could be in one file, and generate variations for different purposes. For those Schemes with cond-expand, we could put them in one file, so we wouldn't have to generate too many files. Since the single-file approach would still require some pre-processing, let me suggest yet another single file approach: shar. A shell archive including several files a little sh-script to glue the pieces together. Still one file. ;-) Irony aside: any tool will do. Simplicity for the end user should be the trumping argument. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
Am 25.11.2013 23:16, schrieb David A. Wheeler: David A. Wheeler scripsit: How about cond-expands at the beginning to handle much of the shimming, On Mon, 25 Nov 2013 12:08:47 -0500, John Cowan co...@mercury.ccil.org wrote: As of the last time I looked, cond-expand wasn't supported by Racket, Scheme48/scsh, Larceny, Ypsilon, S7, or Sizzle. Whow! What an impressive list! It just gets worser and worser. Putting the text in *different* files and leaving them there *also* appears to be non-portable: * R5RS load doesn't guarantee that loading is relative to the directory of the current file (or provide any other guarantee about current directory), and has no include at all. * R7RS does have include (4.1.7. Inclusion), though it merely encourages searching the same directory as the caller of include (and certainly doesn't guarantee searching there FIRST, so it's just begging for security vulnerabilities just like PATH=.:$PATH). Plus: different compilers will need specific care anyway. After all, you don't want to use load at all, since it may compile into a call to load with a given file name, which defeats the very purpose of compilation. Maybe it's time to break out cpp or sed :-(, or use some other tool to generate various files for different Scheme implementations. At this point it might be rather easy to explain a second (and more general) use case of my idea of having a Scheme reader which returns comments are nodes in the AST. I already wrote such a tool for my own purpose (even though does currently not include comments in the translated files, which is not bad in principle, but still bad in practise). Helps me to expand cond-expand sections, overcome my inability to get hygienic macros work in rscheme and expand some parsers written using lalr for chicken. It even implements the make macro from PLT (which I tested by writing a replacement of the make process for chicken)... Neatly a tool but see below... The configure program already modifies the file anyway, so that might not be insane. Hm. Depends on the stance you take wrt. configure. ;-/ At the least, I could put things in different files, and then use cat to create files usable to different systems. Not too bad and idea. While it might not scale to whole programs, it's certainly a valid way to get things done for something the size of a srfi's implementation. I'll note that my Common Lisp implementation just works, and it even overrides the reader. In contrast, a common answer seems to be don't bother trying to write portable Scheme: http://stackoverflow.com/questions/11062320/writing-portable-scheme-code-is-anything-standard-beyond-r5rs-itself Thanks for this pointer. It took me to http://www.ccs.neu.edu/home/dorai/scmxlate/ which I have not yet heard about. There is so much we don't ever see. Maybe I can retire the preprocessor mentioned above. Though probably not: just found out that at minimum I would have to add rscheme to scmxlate. Also it seems a bit hard to use and even harder to use in batch mode. I *like* Scheme, but it's starting to feel like an abusive relationship :-). Yeah, sometimes I feel that way too. John, how do you manage to keep a positive mood when dealing with so many implementations? -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
I said: I'll note that my Common Lisp implementation just works, On Tue, 26 Nov 2013 11:29:49 -0500, John Cowan co...@mercury.ccil.org wrote: Well, yes. Common Lisp is a pretty thorough standard, and as such it has a fairly large number of actively developed implementations, as languages go: ABCL, CCL, CLISP, CMUCL, ECL, MKCL, SBCL. But that's nothing compared to Scheme's seventy-seven or so. It's not the number of implementations, it's the lack of a widely-implemented standard way to invoke basic capabilities, such as a module system, exception system, and hash tables. Heck, not even macros (a Lisp basic) are completely universal. If there were 77 Schemes that agreed on all those, it'd be fine. As a developer, I stick to Chicken and Chibi, and resolutely ignore the (mis)behavior of other Schemes. I have the same basic approach (using guile as the list). Here's hoping that R7RS, especially R7RS-large, will make it possible to unify the islands. I think Scheme would be more compelling if people could actually work together :-). --- David A. Wheeler -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
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. * 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. 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. --- David A. Wheeler -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
John Cowan: Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries can't be the result of a macro, neither as a whole nor in part. All you've done is trade off one set of portability breakers for another. Ugh. In that case, maybe we should just drop the readable-kernel-module-contents macro altogether, and just write straight code with weird names to reduce possible namespace problems. We can include cond-expand guile magic so that it works as-is as a guile module. Alan: Any objections? John: I take it that prefixed % is a universally-portable indicator we can use for internal names? Adapting it to X Scheme's notion of a module should be left to X Scheme experts. The notion that you have to be an X Scheme expert to merely define or use a module is absurdly broken. Here's to hoping that R7RS library module notation gets universally implemented, and quickly, so that such nonsense can go to the dustbin of history. This is what I've been doing with my SRFI implementations: plain code, plus a shim file to add stuff from R7RS-small that I need, plus modules for Chicken (R5RS-plus) and Chibi (R7RS), both of which fortunately support include. Yes, it's more complex to use than one all-singing-all-dancing file. But it's much easier to port, even if it does less of the work for you. How about cond-expands at the beginning to handle much of the shimming, followed by clean code, and separate files to create modules and include them? That should be fairly widely available (I hope!). --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
David A. Wheeler scripsit: How about cond-expands at the beginning to handle much of the shimming, On Mon, 25 Nov 2013 12:08:47 -0500, John Cowan co...@mercury.ccil.org wrote: As of the last time I looked, cond-expand wasn't supported by Racket, Scheme48/scsh, Larceny, Ypsilon, S7, or Sizzle. 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). Maybe it's time to break out cpp or sed :-(, or use some other tool to generate various files for different Scheme implementations. The configure program already modifies the file anyway, so that might not be insane. At the least, I could put things in different files, and then use cat to create files usable to different systems. 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 I *like* Scheme, but it's starting to feel like an abusive relationship :-). --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
David A. Wheeler scripsit: ; Set up what we must at the topmost layer, and then define and invoke: ; (readable-kernel-module-contents (exports ...) body ...) ; - a macro that should package the given body as a module, or whatever your ; scheme calls it (chicken eggs?), Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries can't be the result of a macro, neither as a whole nor in part. All you've done is trade off one set of portability breakers for another. I recommend you do what Schemers have done from time immemorial: just write straight code, using a convention like prefixed % for internal-only functions and macros. That way you can load it in any Scheme (within reason) and watch it work. Adapting it to X Scheme's notion of a module should be left to X Scheme experts. This is what I've been doing with my SRFI implementations: plain code, plus a shim file to add stuff from R7RS-small that I need, plus modules for Chicken (R5RS-plus) and Chibi (R7RS), both of which fortunately support include. Yes, it's more complex to use than one all-singing-all-dancing file. But it's much easier to port, even if it does less of the work for you. -- Long-short-short, long-short-short / Dactyls in dimeter, John Cowan Verse form with choriambs / (Masculine rhyme): co...@ccil.org One sentence (two stanzas) / Hexasyllabically Challenges poets who / Don't have the time. --robison who's at texas dot net -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
