Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
On Thu, Apr 18, 2013 at 6:03 AM, Arne Babenhauserheide wrote: > Am Mittwoch, 17. April 2013, 21:58:28 schrieb Alan Manuel Gloria: > > On Wed, Apr 17, 2013 at 8:06 PM, Arne Babenhauserheide >wrote: > > > > > At Wed, 17 Apr 2013 06:39:37 +0800, > > > almkglor wrote: > > > > Macros were not standard until R4RS, either (although most Scheme > systems > > > > pre-R4RS did have a Common Lisp-like unhygienic macro system). A > better > > > > > > I did not know that… I had thought that lisps had macros from very > early > > > on. > > > > > > > Going seriously off-topic, but well... > > I don’t consider the history of Lisp to be off-topic when we’re discussion > what will hopefully be part of its future :) > > > (define-macro (example x) > > `(foo ,x)) > > > > and consider what happens when it's used in a context where 'foo is bound > > locally: > > > > (let ((foo #t)) > > (example foo)) > > ==> > > (let ((foo #t)) > > (foo foo)) > > > On a Lisp-2, (foo foo) means "call the globally-bound function named 'foo > > with the current value of the variable 'foo". Common Lisp augments this > > further with an excellent package system that essentially changes (?) a > > symbol's identity - 'foo in one package does not evaluate to the same > > symbol as 'foo in another package unless it's been imported (if I > > understood Common Lisp correctly, LOL). In a Lisp-1 like Scheme, it > means > > "call the current value of the variable 'foo with itself." Schemers also > > prefer not to use Common Lisp's package system, often using lexical > binding > > to provide some kind of package system. > > > > This lead to a lot of research into "hygienic macro expanders", which I > > *think* is not yet *quite* resolved today (there are two main branches of > > hygienic macro expanders, the syntax-case branch and the > > syntactic-closures/explicit-renaming branches, the syntax-rules system > can > > be implemented on top of either, Andre van Tonder did an implementation > > that supposedly implements both syntax-case and explicit-renaming (but > not > > syntactic-closures, I think) > > It’s strange to see that many problems in what I consider as one of the > most powerful feature of Lisp. > > Anything with a lot of power has the risk of being horribly abused and misused. Much of the research seems to be how to put proper safety locks on a very powerful weapon so you don't accidentally shoot your foot, and the *proper* shape of the safety lock. Everyone agrees a safety lock is good (i.e. syntax-rules). People are (still?) arguing about the shape of the lock (syntax-case or explicit-renaming/syntactic-closures). > > Most coders would put a single module's code inside a single file, with > > one-file-per-module. So it's not an issue, if it's in the file, it's > part > > of the module, indentation or no indentation > > Is there some automatism for that? > Not sure, it's just a habit based on the simplest way to write a Scheme interpreter (i.e. load all the defines in this file), so most Scheme implementations will just build up their module systems on top of that. > > > > Can the module reuse defines outside the module to avoid that? > > > > > > > > Most module systems allow importing another module's exported bindings, > and > > few might be able to import "global" bindings, whatever "global" might > mean > > for your Scheme system's module system. > > Is “top-level in the file” global? > Depends. In Guile if there's a module declaration then anything in the top-level is part of the module. Otherwise, it depends: earlier versions had a "global" namespace, Guile-2 (maybe?) I think has a separate namespace for REPL. Again, it depends on the exact implementation. The only thing you can rely on is that a series of defines in a file will usually be loadable/compileable in any Scheme; whether it's "global", or put in some kind of module implicitly, or something else, depends on the Scheme. > > For example in Python you have to jump through some hoops if you want to > use a function as method, but it is possible for most cases (there is the > module functools dedicated to that and related hackery…). > > Thanks for your background info! > > Best wishes, > Arne > -- > singing a part of the history of free software: > > - http://infinite-hands.draketo.de > > -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
Alan Manuel Gloria scripsit: > This lead to a lot of research into "hygienic macro expanders", which I > *think* is not yet *quite* resolved today (there are two main branches of > hygienic macro expanders, the syntax-case branch and the > syntactic-closures/explicit-renaming branches, They differ in how they implement non-hygienic macros. When it comes to hygienic macros, they are equal in power. Nobody knows if syntax-case and syntactic-closures non-hygienic macros are equal in power or not. -- Evolutionary psychology is the theory John Cowan that men are nothing but horn-dogs, http://www.ccil.org/~cowan and that women only want them for their money. co...@ccil.org --Susan McCarthy (adapted) -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
David A. Wheeler scripsit: > What's amazing is that the 2 most common Lisps today, Common Lisp and > Scheme, use *static* (lexical) scoping. It shows how influential the Great Quux has been in language design; after all, he was in substantial part responsible for both Scheme and CL (to say nothing of Java). > When I learned Lisp (1980s), "everybody" used dynamic scoping, there > were lots of smart people who said that static scoping would not be > a good idea for Lisps, and I even read arguments as to why dynamic > scoping had to be much more efficient. If memory is very very scarce, as it was in the 1970s, then dynamic scope is acceptably performant in space and time, which almost compensates for its utter lack of transparency. Even RMS only says nowadays that dynamic scope is a Good Thing to have, not that it's the best Default Thing. IMHO first-class parameters (typically, but not always, held in global variables) are far superior to dynamically scoped variables. -- John Cowan co...@ccil.org http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
Alan Manuel Gloria: > Going seriously off-topic, but well... Lisp was originally just 'eval (in > fact, the first Lisp implementation was just an eval implementation in a > single page of code by John McCarthy). Very soon after that, macros were > invented. At Lisp spread, scoping was some sort of dynamic rather than > lexical, ... What's amazing is that the 2 most common Lisps today, Common Lisp and Scheme, use *static* (lexical) scoping. When I learned Lisp (1980s), "everybody" used dynamic scoping, there were lots of smart people who said that static scoping would not be a good idea for Lisps, and I even read arguments as to why dynamic scoping had to be much more efficient. Common Lisp also supports dynamic scoping, but its default is static. Emacs Lisp and some other lisps use only dynamic scoping, but dynamic scoping is no longer "what all Lisps do". --- David A. Wheeler -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
Am Mittwoch, 17. April 2013, 10:19:21 schrieb John Cowan: > Arne Babenhauserheide scripsit: > > > I did not know that… I had thought that lisps had macros from very > > early on. > > Oh yes. Lisp implementations of all sorts have had macros of one kind > or another, with the exception of very small implementations from earlier > days. But having macros and standardizing them are two different > things. Common Lisp standardized its low-level non-hygienic macros > in CLtL1 (1984). Scheme did not standardize its high-level hygienic > macros until R4RS (1991), and then only in a non-normative appendix; full > standardization did not come until R5RS (1998). Low-level macros with > optional hygiene-breaking were standardized by R6RS (2007); they were > excluded from the small language of R7RS, but will reappear in some form > in the large language. Wow… so that’s actually pretty recent research. To think that I took my Emacs Lisp macros for granted… Thanks! Best wishes, Arne -- A man in the streets faces a knife. Two policemen are there it once. They raise a sign: “Illegal Scene! Noone may watch this!” The man gets robbed and stabbed and bleeds to death. The police had to hold the sign. …Welcome to Europe, citizen. Censorship is beautiful. ( http://draketo.de/stichwort/censorship ) signature.asc Description: This is a digitally signed message part. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
Am Mittwoch, 17. April 2013, 21:58:28 schrieb Alan Manuel Gloria: > On Wed, Apr 17, 2013 at 8:06 PM, Arne Babenhauserheide wrote: > > > At Wed, 17 Apr 2013 06:39:37 +0800, > > almkglor wrote: > > > Macros were not standard until R4RS, either (although most Scheme systems > > > pre-R4RS did have a Common Lisp-like unhygienic macro system). A better > > > > I did not know that… I had thought that lisps had macros from very early > > on. > > > > Going seriously off-topic, but well... I don’t consider the history of Lisp to be off-topic when we’re discussion what will hopefully be part of its future :) > (define-macro (example x) > `(foo ,x)) > > and consider what happens when it's used in a context where 'foo is bound > locally: > > (let ((foo #t)) > (example foo)) > ==> > (let ((foo #t)) > (foo foo)) > On a Lisp-2, (foo foo) means "call the globally-bound function named 'foo > with the current value of the variable 'foo". Common Lisp augments this > further with an excellent package system that essentially changes (?) a > symbol's identity - 'foo in one package does not evaluate to the same > symbol as 'foo in another package unless it's been imported (if I > understood Common Lisp correctly, LOL). In a Lisp-1 like Scheme, it means > "call the current value of the variable 'foo with itself." Schemers also > prefer not to use Common Lisp's package system, often using lexical binding > to provide some kind of package system. > > This lead to a lot of research into "hygienic macro expanders", which I > *think* is not yet *quite* resolved today (there are two main branches of > hygienic macro expanders, the syntax-case branch and the > syntactic-closures/explicit-renaming branches, the syntax-rules system can > be implemented on top of either, Andre van Tonder did an implementation > that supposedly implements both syntax-case and explicit-renaming (but not > syntactic-closures, I think) It’s strange to see that many problems in what I consider as one of the most powerful feature of Lisp. > Most coders would put a single module's code inside a single file, with > one-file-per-module. So it's not an issue, if it's in the file, it's part > of the module, indentation or no indentation Is there some automatism for that? > > Can the module reuse defines outside the module to avoid that? > > > > > Most module systems allow importing another module's exported bindings, and > few might be able to import "global" bindings, whatever "global" might mean > for your Scheme system's module system. Is “top-level in the file” global? For example in Python you have to jump through some hoops if you want to use a function as method, but it is possible for most cases (there is the module functools dedicated to that and related hackery…). Thanks for your background info! Best wishes, Arne -- singing a part of the history of free software: - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
Arne Babenhauserheide scripsit: > I did not know that… I had thought that lisps had macros from very > early on. Oh yes. Lisp implementations of all sorts have had macros of one kind or another, with the exception of very small implementations from earlier days. But having macros and standardizing them are two different things. Common Lisp standardized its low-level non-hygienic macros in CLtL1 (1984). Scheme did not standardize its high-level hygienic macros until R4RS (1991), and then only in a non-normative appendix; full standardization did not come until R5RS (1998). Low-level macros with optional hygiene-breaking were standardized by R6RS (2007); they were excluded from the small language of R7RS, but will reappear in some form in the large language. -- John Cowanco...@ccil.orghttp://ccil.org/~cowan Half the lies they tell about me are true. --Tallulah Bankhead, American actress -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
On Wed, Apr 17, 2013 at 8:06 PM, Arne Babenhauserheide wrote: > At Wed, 17 Apr 2013 06:39:37 +0800, > almkglor wrote: > > Macros were not standard until R4RS, either (although most Scheme systems > > pre-R4RS did have a Common Lisp-like unhygienic macro system). A better > > I did not know that… I had thought that lisps had macros from very early > on. > Going seriously off-topic, but well... Lisp was originally just 'eval (in fact, the first Lisp implementation was just an eval implementation in a single page of code by John McCarthy). Very soon after that, macros were invented. At Lisp spread, scoping was some sort of dynamic rather than lexical, and people were not really concerned with large-scale programming, and most Lisp's were Lisp-2's (function/macro/special form names were separate from variables, so you could, say, have a 'if special form and an 'if variable binding). Fast forward a couple decades and Sussman and Steele start dabbling on a language called Schemer. It had lexical scope and was a Lisp-1, meaning that function names were in the same namespace as values. This started causing problems with the "ordinary" macros of most Lisp's available at the time. In particular, consider a macro that expands to a function call to a function named 'foo: (define-macro (example x) `(foo ,x)) and consider what happens when it's used in a context where 'foo is bound locally: (let ((foo #t)) (example foo)) ==> (let ((foo #t)) (foo foo)) On a Lisp-2, (foo foo) means "call the globally-bound function named 'foo with the current value of the variable 'foo". Common Lisp augments this further with an excellent package system that essentially changes (?) a symbol's identity - 'foo in one package does not evaluate to the same symbol as 'foo in another package unless it's been imported (if I understood Common Lisp correctly, LOL). In a Lisp-1 like Scheme, it means "call the current value of the variable 'foo with itself." Schemers also prefer not to use Common Lisp's package system, often using lexical binding to provide some kind of package system. This lead to a lot of research into "hygienic macro expanders", which I *think* is not yet *quite* resolved today (there are two main branches of hygienic macro expanders, the syntax-case branch and the syntactic-closures/explicit-renaming branches, the syntax-rules system can be implemented on top of either, Andre van Tonder did an implementation that supposedly implements both syntax-case and explicit-renaming (but not syntactic-closures, I think) but I don't see (?) it used often), except that most users seem to prefer the syntax-case branch, but the Scheme implementers (?) seem to prefer syntactic-closures/explicit-renaming (which makes sense because syntax-case needs some integration into your compiler/interpreter, and it's somewhat harder to get a *simple* s-expression that is the macro-expansion of the syntax-case output, syntax-case output has to be a somewhat richer AST; van Tonder's attempt I think restricts the special annotations only to symbols, whereas syntax-case as originally conceived had annotations infecting all nodes to prevent the O(n^2) behavior of a similar but simpler ancestor of syntax-case). In fact, the inclusion of syntax-case in the R6RS branch seems to be a minor contributor to its de facto rejection. > > > > Can’t they simply use the “ignore whitespace change” options to diff? > > > > > > > Err, that would have to be in *patch*, not in diff. But it would mess up > > the indentation afterwards if you applied an indented patch into an > > unindented source (entirely new lines in the code would be indented more > > than their surroundings) or vice versa. So it's less ideal for the > > maintainer, since applying patches becomes more complex. Simpler to just > > start all defines at indent 0, and for code in a module-is-one-datum > > system, just wrap all the defines in the module annotation without > > disturbing their indentations. > > That’s right, yes… I think it hurts clarity (you cannot see at one > glance whether the define is part of the module or not), but I can see > the convenience advantage for maintaining the code. > Most coders would put a single module's code inside a single file, with one-file-per-module. So it's not an issue, if it's in the file, it's part of the module, indentation or no indentation > > Can the module reuse defines outside the module to avoid that? > > Most module systems allow importing another module's exported bindings, and few might be able to import "global" bindings, whatever "global" might mean for your Scheme system's module system. Sincerely, AmkG -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
At Wed, 17 Apr 2013 06:39:37 +0800, almkglor wrote: > Macros were not standard until R4RS, either (although most Scheme systems > pre-R4RS did have a Common Lisp-like unhygienic macro system). A better I did not know that… I had thought that lisps had macros from very early on. > > Can’t they simply use the “ignore whitespace change” options to diff? > > > > Err, that would have to be in *patch*, not in diff. But it would mess up > the indentation afterwards if you applied an indented patch into an > unindented source (entirely new lines in the code would be indented more > than their surroundings) or vice versa. So it's less ideal for the > maintainer, since applying patches becomes more complex. Simpler to just > start all defines at indent 0, and for code in a module-is-one-datum > system, just wrap all the defines in the module annotation without > disturbing their indentations. That’s right, yes… I think it hurts clarity (you cannot see at one glance whether the define is part of the module or not), but I can see the convenience advantage for maintaining the code. Can the module reuse defines outside the module to avoid that? Best wishes, Arne -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
At Tue, 16 Apr 2013 18:18:53 -0400 (EDT), dwheeler wrote: > > On Tue, 16 Apr 2013 14:44:00 +0200, Arne Babenhauserheide > wrote: > Awesome! I've tried to merge in your additional comments, thanks. Thanks! > > I think I would > > end a statement at 2 empty lines, which would mean that you *should > > not* use 2 consecutive empty lines in a script (but you could). > > Hmm, that's something we could do too, though that would trade off less > well to interactive use (then you have to press Enter 3 times). Yes. It’s less convenient than just having to press twice, so it is a tradeoff. But I think it should work for sweet expressions, too. It makes it easier to avoid huge blocks of text. Best wishes, Arne -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
Alan Manuel Gloria scripsit: > Macros were not standard until R4RS, either (although most Scheme systems > pre-R4RS did have a Common Lisp-like unhygienic macro system). A better > way would be to make a function that displays multiple values, but if you > start doing that, you'll start wanting the full (format ...) anyway, so you > either choose to write out a bunch of (display x) ... forms, or > re-implementing (format ...) Or use "fmt" format combinators, which I have proposed as the formatting mechanism for the large language. -- That you can cover for the plentifulJohn Cowan and often gaping errors, misconstruals, http://www.ccil.org/~cowan and disinformation in your postsco...@ccil.org through sheer volume -- that is another misconception. --Mike to Peter -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
On Wed, Apr 17, 2013 at 6:18 AM, Arne Babenhauserheide wrote: > Hi Alan, > > Thank you for your answer! > > Am Dienstag, 16. April 2013, 06:27:21 schrieb Alan Manuel Gloria: > > > old: would not be written like that (though you can)… > > > > > > begin > > > . (display "Welcome, ") (display player) (display ", to > Chicago!") > > > (newline) > > > > > > but rather like this: > > > > > > begin > > > display "Welcome, " > > > display player > > > display ", to Chicago!" > > > newline > > > > > > > > Actually, some Lisp programmers may prefer the former; (display > something) > > (newline) is idiomatic in Scheme since (format ) was not standardized > until > > an SRFI, and may not be available (and so displaying something on a line > by > > itself is better put in a single physical line in code, hence the > (display > > foo) (newline) all-on-a-line idiom. Also note that because (format ...) > > was late in standardization, many would prefer to put a sequence of > > (display ...) forms on a single physical line). > > That feels pretty strange for me. The first thing I though there was to > write a macro which displays multiple values… > Macros were not standard until R4RS, either (although most Scheme systems pre-R4RS did have a Common Lisp-like unhygienic macro system). A better way would be to make a function that displays multiple values, but if you start doing that, you'll start wanting the full (format ...) anyway, so you either choose to write out a bunch of (display x) ... forms, or re-implementing (format ...) > > So I did not think about that, but it’s quite possible, that this will > disturb some. I hope that others will appreciate the clarity… > > What I would do in Emacs Lisp: > > defmacro show : &rest args > cons 'progn > loop for arg in args collect > list 'message : list 'number-to-string arg > > > In Scheme, usually you just put a bunch of definitions (unindented) in a > > file, then load them in your favorite Scheme system. After you've hacked > > on the definitions on the file a bit, *then* you put the module > > annotations. This is largely the rationale for (include ...) in R7RS > > (define-library ...) forms: the expected Scheme workflow is to start > with a > > bunch of top-level, non-module definitions, hack on them until they work, > > then put them in a module. Hence, support for a bunch of unindented > > definitions inside a module would be nice. > > To me statically indenting a block of code seems quite simple - at least > Emacs does it in a blink, and I assume vim likewise. > > Yes, indeed, but : > > different segments of their users - including patches. By keeping their > > published code unindented, such a maintainer could apply the same patch, > > from say a primarily-Guile user, to both the official Guile and MzScheme > > code. > > Can’t they simply use the “ignore whitespace change” options to diff? > Err, that would have to be in *patch*, not in diff. But it would mess up the indentation afterwards if you applied an indented patch into an unindented source (entirely new lines in the code would be indented more than their surroundings) or vice versa. So it's less ideal for the maintainer, since applying patches becomes more complex. Simpler to just start all defines at indent 0, and for code in a module-is-one-datum system, just wrap all the defines in the module annotation without disturbing their indentations. > > Best wishes, > Arne > -- > 1w6 sie zu achten, > sie alle zu finden, > in Spiele zu leiten > und sacht zu verbinden. > → http://1w6.org > -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
Hi Alan, Thank you for your answer! Am Dienstag, 16. April 2013, 06:27:21 schrieb Alan Manuel Gloria: > > old: would not be written like that (though you can)… > > > > begin > > . (display "Welcome, ") (display player) (display ", to Chicago!") > > (newline) > > > > but rather like this: > > > > begin > > display "Welcome, " > > display player > > display ", to Chicago!" > > newline > > > > > Actually, some Lisp programmers may prefer the former; (display something) > (newline) is idiomatic in Scheme since (format ) was not standardized until > an SRFI, and may not be available (and so displaying something on a line by > itself is better put in a single physical line in code, hence the (display > foo) (newline) all-on-a-line idiom. Also note that because (format ...) > was late in standardization, many would prefer to put a sequence of > (display ...) forms on a single physical line). That feels pretty strange for me. The first thing I though there was to write a macro which displays multiple values… So I did not think about that, but it’s quite possible, that this will disturb some. I hope that others will appreciate the clarity… What I would do in Emacs Lisp: defmacro show : &rest args cons 'progn loop for arg in args collect list 'message : list 'number-to-string arg > In Scheme, usually you just put a bunch of definitions (unindented) in a > file, then load them in your favorite Scheme system. After you've hacked > on the definitions on the file a bit, *then* you put the module > annotations. This is largely the rationale for (include ...) in R7RS > (define-library ...) forms: the expected Scheme workflow is to start with a > bunch of top-level, non-module definitions, hack on them until they work, > then put them in a module. Hence, support for a bunch of unindented > definitions inside a module would be nice. To me statically indenting a block of code seems quite simple - at least Emacs does it in a blink, and I assume vim likewise. > different segments of their users - including patches. By keeping their > published code unindented, such a maintainer could apply the same patch, > from say a primarily-Guile user, to both the official Guile and MzScheme > code. Can’t they simply use the “ignore whitespace change” options to diff? Best wishes, Arne -- 1w6 sie zu achten, sie alle zu finden, in Spiele zu leiten und sacht zu verbinden. → http://1w6.org signature.asc Description: This is a digitally signed message part. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
On Tue, 16 Apr 2013 14:44:00 +0200, Arne Babenhauserheide wrote: > Hi David, > > I now read the comparison to wisp, and I agree with everything you > write in there. Especially the conclusion nicely sums up the > differences between readable (with the goal on readability) and wisp > (with the goal on simplicity). Awesome! I've tried to merge in your additional comments, thanks. > I think I would > end a statement at 2 empty lines, which would mean that you *should > not* use 2 consecutive empty lines in a script (but you could). Hmm, that's something we could do too, though that would trade off less well to interactive use (then you have to press Enter 3 times). --- David A. Wheeler -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Comparision to wisp in SRFI; Was: Re: wisp: Whitespace to Lisp: An indentation to brackets preprocessor
On Mon, Apr 15, 2013 at 11:00 PM, Arne Babenhauserheide wrote: > Hi, > > Could you change the comparision in the SRFI¹ from my first email to the > real implementation in Wisp? > > ¹: http://srfi.schemers.org/srfi-110/srfi-110.html#arne > > Changes: > > - the sublist with inline : always ends at the end of the line (thanks to > Alan) > - inconsistent dedents produce broken code (they *should* throw an error). > - the name is wisp :) > > This means that some examples change: > > first: should not use double colons: > > let : : x : compute 'x > : y : compute 'y > use x y > > new: > > let > : > x : compute 'x > y : compute 'y > use x y > > > SUBLIST comparison: > > old: would not be written like that (though you can)… > > begin > . (display "Welcome, ") (display player) (display ", to Chicago!") > (newline) > > but rather like this: > > begin > display "Welcome, " > display player > display ", to Chicago!" > newline > > Actually, some Lisp programmers may prefer the former; (display something) (newline) is idiomatic in Scheme since (format ) was not standardized until an SRFI, and may not be available (and so displaying something on a line by itself is better put in a single physical line in code, hence the (display foo) (newline) all-on-a-line idiom. Also note that because (format ...) was late in standardization, many would prefer to put a sequence of (display ...) forms on a single physical line). > or like this, if you want more complex expressions: > > begin > display > concat "Welcome, " player > . ", to Chicago!" > newline > > > This uses more vertical space - and I don’t mind (so it is a design > choice not to try very hard to minimize vertical space). > > > For the single gigantic top-level datum, you just indent the rest (as in > class definitions in Python): > > library : example > import : scheme base > export . > example-init example-open example-close > begin > define : example-init > whatever ... > ... > > define : example-open x > whatever ... > ... > > define : example-close y > whatever ... > ... > > In Scheme, usually you just put a bunch of definitions (unindented) in a file, then load them in your favorite Scheme system. After you've hacked on the definitions on the file a bit, *then* you put the module annotations. This is largely the rationale for (include ...) in R7RS (define-library ...) forms: the expected Scheme workflow is to start with a bunch of top-level, non-module definitions, hack on them until they work, then put them in a module. Hence, support for a bunch of unindented definitions inside a module would be nice. This is largely due to history: Scheme did not have cross-system standard modules. Most coders will have two or so Scheme systems they work in, and they might want to hack on their code first on one, then on the other(s). A flat file of definitions would usually work portably across Scheme systems. So Schemers generally have the habit of putting module annotations as the last step just prior to publishing their code. Those interested in cross-Scheme compatibility for their published code might very well keep the definitions unindented - some Schemes require modules to be a single large datum (MzScheme, R6RS, R7RS) others require module annotations as a separate datum(s) before definitions (Guile), and a Schemer maintaining a cross-platform library might get bug reports from different segments of their users - including patches. By keeping their published code unindented, such a maintainer could apply the same patch, from say a primarily-Guile user, to both the official Guile and MzScheme code. > I’m used to pythen, and to me this looks completely natural. Compare: > > class example: > def __init__(): > import base > print base.stuff > def localfunc(): > whatever … > … > > Best wishes, > Arne > > At Mon, 01 Apr 2013 23:53:57 +0200, > Arne Babenhauserheide wrote: > > > > [1 ] > > [1.1 ] > > Am Donnerstag, 28. März 2013, 18:31:04 schrieb David A. Wheeler: > > > Arne Babenhauserheide: > > > > I finally managed to get the simple indentation to lisp preprocessor > into a working state and thought you might be interested. > > > > > > Absolutely!! > > > > Glad to hear that! :) > > > > > ... > > > > But at least I managed to write a real release text with an > explanation of the syntax and code-examples: > > > > http://draketo.de/light/english/wisp-lisp-indentation-preprocessor > > > > > > Thanks! I just added that URL link to the SRFI Alan and I are > developing. That way, anyone who might be interested can jump straight to > your stuff. > > > > Cool - thanks! > > > > > > PS: @David: I just realized that I had missed quite a few of your > ans
