| |||||||||||||
Curly-infix and readable LispCurly-infix and readable LispPosted Dec 3, 2012 22:51 UTC (Mon) by HelloWorld (guest, #56129)In reply to: Curly-infix and readable Lisp by david.a.wheeler Parent article: GNU Guile 2.0.7 released
Thank you for the project, I'm sure that this will make Lisp more accessible to the many many people who were put off by its syntax. Too bad Guile didn't adopt all your syntax improvements...
(Log in to post comments)
Don't worry - we're not done! Posted Dec 3, 2012 23:11 UTC (Mon) by david.a.wheeler (guest, #72896) [Link]
In Scheme, changes are more widely accepted if they are formalized into a SRFI specification. Curly-infix was only recently formalized into a SRFI; the final version was only released a month ago (2012-11-01). The plan is to get sweet-expressions defined in a SRFI, and then get that implemented everywhere (like guile) as well. Since sweet-expressions build on curly-infix expressions, the release of SRFI-105 and its implementation in guile are key steps to getting there.
Don't worry - we're not done! Posted Dec 4, 2012 1:46 UTC (Tue) by HelloWorld (guest, #56129) [Link] The code generated by the sweeten tool doesn't seem optimal yet though. For example,(defun foo (bar baz) ...) is rewritten into defun foo bar(baz) .... I think the natural way to write this would be
defun foo bar baz ...But maybe that's just me.
Sweeten results Posted Dec 4, 2012 14:19 UTC (Tue) by david.a.wheeler (guest, #72896) [Link] Since "sweeten" is a pretty-printer, there will always be cases where people will differ on what's "pretty". That said, suggestions to improve it are very welcome; my hope is that "sweeten" will make it easy for people to switch to sweet-expressions. So let's take a look. First of all, we both agree that the expression: (defun foo (bar baz) ...)can be rewritten either as: defun foo bar(baz)or as:
defun foo
bar baz
...
So, when sweeten rewrites existing code, what form *should* it prefer? I think this format is sensible when you see stuff like this: define cos1 cos(1)which is why I wrote the heuristic to do this. The current heuristic for determining if something should be in one line is (in this case) implemented in the "sweeten-top" function, as follows:
if { {length-asline < max-unit-character-length} and
fits-width?(indent-already indent length-asline) and
{general-length(m) < max-unit-list-length} }
....
Since:
define maxwidth 78 define max-unit-character-length 60 define max-unit-list-length 8The current "sweeten" does what it does. Feel free to suggest a better heuristic! For more discussions, please join the "readable" mailing list, where this sort of discussion takes place: http://readable.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Sweeten results Posted Dec 4, 2012 15:42 UTC (Tue) by HelloWorld (guest, #56129) [Link] Hi David,
For personal reasons, I don't want to sign up to the mailing list. Anyway, whether the defun foo bar(baz) ...syntax is that the first argument is outside of the parenthesis, while the following arguments are within, suggesting that the first argument is somehow different even though it really isn't. defun foo bar baz ...fixes that. There's also another way to write it: defun foo (bar baz) ...(I thought that would be rewritten into (defun (foo bar baz) ...) at first, but it actually works due to the space following foo).
My main point here is that the heuristic should special-case some forms. defun is one, another obvious one is lambda for the same reason.
I've modified "sweeten" per your suggestion Posted Dec 5, 2012 2:01 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] HelloWorld said:... The problem with the
defun foo bar(baz)
...
syntax is that the first argument is outside of the parenthesis, while the following arguments are within, suggesting that the first argument is somehow different even though it really isn't. ... There's also another way to write it:
defun foo (bar baz)
...
My main point here is that the heuristic should special-case some forms. defun is one, another obvious one is lambda for the same reason. The "sweeten" tool actually already special-cases some forms, but since I use it more for Scheme than Common Lisp, its special-case form for "defun" wasn't all that great. Thanks for the feedback, that's a good point. I've modified "sweeten" in the development branch, it now handles "defun" specially and will output the format you suggested above. This change will get rolled into the next "official" release, but feel free to try it out now. Enjoy!
I've modified "sweeten" per your suggestion Posted Dec 5, 2012 2:06 UTC (Wed) by HelloWorld (guest, #56129) [Link]
I'm glad I could help.
doesn't work :( Posted Dec 5, 2012 11:09 UTC (Wed) by HelloWorld (guest, #56129) [Link] Hey David, I just checked out sweeten from the git repository on sourceforge, and I can't see the change.$ ./sweeten <<< '(defun foo (bar baz) ...)' defun foo bar(baz) ...The first parameter is still outside the parenthesis :(
It works - you need to check out the develop branch Posted Dec 5, 2012 19:42 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] It works, you just need to check out the *develop* branch in the git repo, not the *master* branch. The master branch represents the currently-released version. Our workflow is described in http://sourceforge.net/p/readable/wiki/Workflow/ and is based on Vincent Driessen's "successful git branching model" workflow. I get: $ ./sweeten <<< '(defun foo (bar baz) ...)' defun foo (bar baz) bar baz ... Which I believe is what you wanted.
It works - you need to check out the develop branch Posted Dec 5, 2012 19:54 UTC (Wed) by HelloWorld (guest, #56129) [Link] Hi, OK, I got the master branch now.$ ./sweeten <<< '(defun foo (bar baz) ...)' defun foo (bar baz) bar baz ...Yes, that is what I get too, but... how does it make sense? The function arguments are there twice now. I'm not much of a Lisp person, but shouldn't it be either defun foo (bar baz) ...or defun foo bar baz ...?
Whups! Bug fixed Posted Dec 5, 2012 21:34 UTC (Wed) by david.a.wheeler (guest, #72896) [Link] how does it make sense? The technical answer is, "because I screwed up" :-). A copy-and-paste error on my part, sorry. I was so focused on getting the first line right that I didn't pay attention to the second line once I got the first line right. I guess I'm still human. I've fixed the bug and posted it on the git repo. I knew there was a reason to have a development branch :-).
|
|||||||||||||