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 arne_...@web.dewrote: Am Mittwoch, 17. April 2013, 21:58:28 schrieb Alan Manuel Gloria: On Wed, Apr 17, 2013 at 8:06 PM, Arne Babenhauserheide arne_...@web.de 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
At Tue, 16 Apr 2013 18:18:53 -0400 (EDT), dwheeler wrote: On Tue, 16 Apr 2013 14:44:00 +0200, Arne Babenhauserheide arne_...@web.de 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
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
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
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
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 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
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 Wed, Apr 17, 2013 at 6:18 AM, Arne Babenhauserheide arne_...@web.dewrote: 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
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
