Re: [Readable-discuss] wisp now defaults to activating curly-infix
At Wed, 19 Nov 2014 15:46:54 -0500 (EST), dwheeler wrote: > > On Wed, 19 Nov 2014 20:48:28 +0100, Arne Babenhauserheide > wrote: > > It’s crazy to think that nowadays it’s actually possible to do > > > > guile -L . --language=wisp tests/factorial.w > > > > and have guile execute the file as real code. > > I guess you know the feeling ☺ > > Right, we got curly-infix in, and that was a great feeling. > > Sweet-expressions are still an external library, and not available through > --language. > Any suggestions on the best way to get them into guile that way? I’d just s̶t̶e̶a̶l̶ build on the wisp-code: https://bitbucket.org/ArneBab/wisp/src/v0.8.1/wisp-reader.w That gets parsed and copied to language/wisp/spec.scm https://bitbucket.org/ArneBab/wisp/src/v0.8.1/bootstrap.sh?at=default#cl-41c It’s not really hard. Best wishes, Arne -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
Am 19.11.2014 um 20:48 schrieb Arne Babenhauserheide:
> And for example today Mu Lei (Nala Ginrut) had the idea of
> representing sxml templates as wisp - a case where I think the sweet
> <* *> syntax could come in really handy.
I can agree. Using SXML with sweet (in that case) works quite well.
Here a ~100kbyte example application (be sure to read in whitespace
preserving mode; my browser gets it wrong):
http://ball.askemos.org/A60aa8b838c61b0de7e9f3cfd5d3ea0c1
(BTW: This is a payment system based on ricardian contracts; quite
different from bitcoin. Currently being documented. More here:
http://ball.askemos.org/?_v=search&_id=1856
http://ball.askemos.org/A5023d27b0e3fce3ee0b12b79e7e337ce
comments welcome.)
Side note: The <* *> can be problematic if your LISP code is itself
embedded in XML formatted source code. Which for me is the case. (To
escape I allowed the {* and *} as to alias those.)
/Jörg
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
Hi David, Am Dienstag, 18. November 2014, 22:28:11 schrieb David A. Wheeler: > > It comes down to personal preferences: The weight we give to different > > aesthetic aspects of programming languages. For me, the syntactic > > simplicity is one of the main selling points of lisp and scheme, and > > sweet departs from that by adding more than the absolute minimum of > > the required syntax elements for creating a general, indentation-based > > representation of scheme-code. > > Neither Scheme nor Common Lisp are so simple to parse once you > consider their full generality (e.g., number types). That hit me with the pure preprocessor… one of the reasons why I switched to using (read) was that I had some longstanding parsing bugs for which I did not have obvious fixes. But that doesn’t mean that the syntax is very complex, just that there are lots of details to take care of. If you hit # a special form begins, strings have some escaping, and otherwise there are the quotes. But maybe my view is a bit biased, because I compare it to Python, Java and C++. Especially C++ ☺ > > Best wishes, > You too! I view this as a friendly competition. > We both agree that there's a need for a Lisp syntax that is > general and homoiconic, and that indentation can help. > We differ on how to best exploit that, that's all. That’s how I see it, too - and we’re also using similar resources (like GNU Guile). On the long run I hope that having two different flavors will help indentation-based syntax for Lisps, because it shows that it’s not just a personal pet-project but rather something of broader appeal. And for example today Mu Lei (Nala Ginrut) had the idea of representing sxml templates as wisp - a case where I think the sweet <* *> syntax could come in really handy. > Thanks. Thank you! Without you I likely would have never been able to reach the point where I can actually write wisp code in the REPL and execute wisp files directly from guile! It’s crazy to think that nowadays it’s actually possible to do guile -L . --language=wisp tests/factorial.w and have guile execute the file as real code. I guess you know the feeling ☺ - 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. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
On Tue, 18 Nov 2014 23:46:44 +0100, Arne Babenhauserheide wrote: > ... Yes, if you know > all the sweet syntax, quite a few code snippets will likely look more > readable than those in wisp. But the additional syntax elements > provide a high barrier for learning, because they require retraining > the eyes. I think that's a trade worth making. More syntax *does* take more training, but if you look at a lot of code, then that additional syntax can pay back large dividends. > > "Less bad" is not exactly a high aspiration :-). > > It’s a different trade-off: Simplicity against less rough edges. ... > > Of course, this why I decided to NOT have all lines begin a function call > > in sweet-expressions. > > Both sweet-expressions and I-expressions (SRFI-49) have a different > > semantic, because it > > seems to be "what humans assume" in practice. > > It’s what lisp and scheme do, but for example it isn’t what the shell > does. I agree that lisp and scheme programmers tend to assume this, > but I don’t think that it is right for indentation-based scheme. But > since this is the main forking point between sweet and wisp, I guess > it isn’t a point which can be changed by argument ☺ Fair enough :-). > It comes down to personal preferences: The weight we give to different > aesthetic aspects of programming languages. For me, the syntactic > simplicity is one of the main selling points of lisp and scheme, and > sweet departs from that by adding more than the absolute minimum of > the required syntax elements for creating a general, indentation-based > representation of scheme-code. Neither Scheme nor Common Lisp are so simple to parse once you consider their full generality (e.g., number types). > The cost I pay for that is that there will be code snippets which will > look less elegant in wisp than in sweet. You could say, that they look > less sweet ☺ ... > Best wishes, > Arne You too! I view this as a friendly competition. We both agree that there's a need for a Lisp syntax that is general and homoiconic, and that indentation can help. We differ on how to best exploit that, that's all. Thanks. --- David A. Wheeler -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
Hi David, Am Donnerstag, 13. November 2014, 18:23:01 schrieb David A. Wheeler: > On Thu, 13 Nov 2014 21:56:19 +0100, Arne Babenhauserheide > wrote: > > I considered it, but decided against it, because in wisp that provides > > less advantages than in sweet expressions, while adding ambiguity (one > > more way to spell the same code). > > I don't think the ability to spell something more than one way is usually > termed "ambiguous"; > I don't know if there's a term for that; perhaps "multiple spellings"? That sounds better, yes. > In any case, "multiple spellings" (or whatever it's called) is inherent in > Scheme and Common Lisp. > For example, 'x and (quote x) are already two ways to write the same thing. These are a bootstrap way and a reader way. 'x actually gets translated to (quote x). In wisp however, `a : b` and `a b()` would both be translated to `a (b)`. They are equivalent spellings which become a common lower-level spelling. I don’t mind having the possibility to write `a b()`, and since wisp requires SRFI-105 for curly-infix, all wisp users should have the option to enable neoteric expressions in any source-file without increasing the requirements for implementors. I just don’t think that it makes sense to push the added complexity on every wisp user *by default*. > Yes, it adds a different way to spell the same code, but in many > cases it would be the more common way to do it (e.g., the normal way > in math and other programming languages). I think that for neoteric expressions the cost outweights the gain while for curly-infix the gain is greater than the cost. A few months ago I had a collegue look at some wisp-code I wrote and he said “I forgot how ugly lisp is”. It turned out that with that he was referring only to prefix-math. > > That expression in wisp is simply > > stuff : cos a … > > In sweet that would be a problem, as far as I know, because if you want to > > do > > > > (stuff (cos a) b c d e) … > > Here neoteric experssions help a lot: > > > > stuff cos(a) b c d e > > That would be the normal way (and recommended) way to do it. > > There are alternatives if you hate neoteric expressions in sweet-expressions, > e.g.: > stuff > cos a \\ b \\ c \\ d \\ e This is part of what made me start to work on wisp in the first place ☺ Too many ways to express something, which I think mainly comes from not being able to continue the argument list easily. Yes, if you know all the sweet syntax, quite a few code snippets will likely look more readable than those in wisp. But the additional syntax elements provide a high barrier for learning, because they require retraining the eyes. > But it seems to that the "obvious" way is the right way: > stuff cos(a) b c d e > > But in wisp you’d just do > > > > stuff : cos a > > . b c d e > > which, though still harder to read than sweet-expressions, is less bad :-). > > "Less bad" is not exactly a high aspiration :-). It’s a different trade-off: Simplicity against less rough edges. > I think wisp is the wrong trade-off anyway, but since you're working on it, > contrast that to: > > > stuff cos(a) > > . b c d e > > which is still harder to read, but less harder :-). It actually looks pretty good, I think. But it does not need to go into the spec, because it is (and should remain) trivial to integrate it later, if it turns out to be needed: Just say “requires activation of neoteric expressions in the reader”. It’s a single line of code for the implementations, so I think it can be done later, if my intuition turns out to be wrong. > > On the other hand, this difference makes neoteric expressions much less > > elegant in wisp than in sweet. In sweet you can just to > > > > stuff > > cos(a) > > > > because a single element on a line is treated as that element, not as a > > function call. In wisp you’d have to do > > > > stuff > > . cos(a) > > > > because a line always begins a function call, except when started with a > > period. > > Of course, this why I decided to NOT have all lines begin a function call in > sweet-expressions. > Both sweet-expressions and I-expressions (SRFI-49) have a different semantic, > because it > seems to be "what humans assume" in practice. It’s what lisp and scheme do, but for example it isn’t what the shell does. I agree that lisp and scheme programmers tend to assume this, but I don’t think that it is right for indentation-based scheme. But since this is the main forking point between sweet and wisp, I guess it isn’t a point which can be changed by argument ☺ It comes down to personal preferences: The weight we give to different aesthetic aspects of programming languages. For me, the syntactic simplicity is one of the main selling points of lisp and scheme, and sweet departs from that by adding more than the absolute minimum of the required syntax elements for creating a general, indentation-based representation of scheme-code. The c
Re: [Readable-discuss] wisp now defaults to activating curly-infix
I said: > > Very cool! Have you considered making neoteric active by default as well? On Thu, 13 Nov 2014 21:56:19 +0100, Arne Babenhauserheide wrote: > I considered it, but decided against it, because in wisp that provides > less advantages than in sweet expressions, while adding ambiguity (one > more way to spell the same code). I don't think the ability to spell something more than one way is usually termed "ambiguous"; I don't know if there's a term for that; perhaps "multiple spellings"? In any case, "multiple spellings" (or whatever it's called) is inherent in Scheme and Common Lisp. For example, 'x and (quote x) are already two ways to write the same thing. Yes, it adds a different way to spell the same code, but in many cases it would be the more common way to do it (e.g., the normal way in math and other programming languages). > That expression in wisp is simply > stuff : cos a > > or > stuff > cos a Sure. You can also do that easily in Sweet-expressions: stuff $ cos a ... or ... stuff cos a > In sweet that would be a problem, as far as I know, because if you want to do > > (stuff (cos a) b c d e) > > without neoteric expressions, you have to do it as > > stuff > cos a > b > c > d > e > > Here neoteric experssions help a lot: > > stuff cos(a) b c d e That would be the normal way (and recommended) way to do it. There are alternatives if you hate neoteric expressions in sweet-expressions, e.g.: stuff cos a \\ b \\ c \\ d \\ e But it seems to that the "obvious" way is the right way: stuff cos(a) b c d e > But in wisp you’d just do > > stuff : cos a > . b c d e > > or > stuff > cos a > . b c d e > which, though still harder to read than sweet-expressions, is less bad :-). "Less bad" is not exactly a high aspiration :-). I think wisp is the wrong trade-off anyway, but since you're working on it, contrast that to: > stuff cos(a) > . b c d e which is still harder to read, but less harder :-). > On the other hand, this difference makes neoteric expressions much less > elegant in wisp than in sweet. In sweet you can just to > > stuff > cos(a) > > because a single element on a line is treated as that element, not as a > function call. In wisp you’d have to do > > stuff > . cos(a) > > because a line always begins a function call, except when started with a > period. Of course, this why I decided to NOT have all lines begin a function call in sweet-expressions. Both sweet-expressions and I-expressions (SRFI-49) have a different semantic, because it seems to be "what humans assume" in practice. I think you're right that in the wisp semantics, using a neoteric expression at the *beginning* of a line would be especially confusing. But not everything is at the beginning of a line, and using them afterwards would (I think) be sensible). E.G.: sqrt cos(a) sin(a) --- David A. Wheeler -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
Hi David,
Am Sonntag, 9. November 2014, 19:10:32 schrieb David A. Wheeler:
> > With the new release of wisp, curly infix is active by default:
> >
> > http://draketo.de/light/english/wisp-lisp-indentation-preprocessor#v0.8.0
> Very cool! Have you considered making neoteric active by default as well?
>
> Then you can do:
>
> stuff cos(a)
I considered it, but decided against it, because in wisp that provides
less advantages than in sweet expressions, while adding ambiguity (one
more way to spell the same code).
That expression in wisp is simply
stuff : cos a
or
stuff
cos a
In sweet that would be a problem, as far as I know, because if you want to do
(stuff (cos a) b c d e)
without neoteric expressions, you have to do it as
stuff
cos a
b
c
d
e
Here neoteric experssions help a lot:
stuff cos(a) b c d e
But in wisp you’d just do
stuff : cos a
. b c d e
or
stuff
cos a
. b c d e
On the other hand, this difference makes neoteric expressions much less elegant
in wisp than in sweet. In sweet you can just to
stuff
cos(a)
because a single element on a line is treated as that element, not as a
function call. In wisp you’d have to do
stuff
. cos(a)
because a line always begins a function call, except when started with a period.
So I’d rather have users enable that manually, if they want it. By enabling
curly-infix, wisp requires SRFI-105, so neoteric expressions should always be
available with wisp (so people can experiment with them and decide whether they
want them, and they don’t have to worry that that brings them incompatibilities
in other wisp implementations).
Curly infix is another matter, because it allows using the language from the
domain of the problem (math):
stuff {3 + 4}
This makes the basics of a very important domain look natural, which everybody
learns in school. Function syntax with f(x) = ... is only taught much later, so
I don’t consider it as similarly essential as infix math notation.
Best wishes,
Arne
signature.asc
Description: This is a digitally signed message part.
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk___
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] wisp now defaults to activating curly-infix
On Mon, 10 Nov 2014 00:27:02 +0100, Arne Babenhauserheide wrote: > Hi, > > With the new release of wisp, curly infix is active by default: > > http://draketo.de/light/english/wisp-lisp-indentation-preprocessor#v0.8.0 > > Also the implementation became more similar to readable (using read > wherever possible). Very cool! Have you considered making neoteric active by default as well? Then you can do: stuff cos(a) --- David A. Wheeler -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] wisp now defaults to activating curly-infix
Hi, With the new release of wisp, curly infix is active by default: http://draketo.de/light/english/wisp-lisp-indentation-preprocessor#v0.8.0 Also the implementation became more similar to readable (using read wherever possible). Best wishes, Arne signature.asc Description: This is a digitally signed message part. -- ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
