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
