[PATCH] Clojure-like syntactic sugar for an anonymous function literal

[PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

[-- Attachment #1: Type: text/plain, Size: 1474 bytes --]

Hi all,

This is my first attempt of modifying the C source of Emacs.
The goal is to add a new reader syntax:

    #(foo bar) should translate to (short-lambda (foo bar))

This is in the same way that the `backquote' is working now:

    `(foo bar) translates to (backquote (foo bar))

The `short-lambda' macro is implemented here:
https://github.com/abo-abo/short-lambda.

In the simplest form, i.e. one that does not allow multiple or
&rest-style arguments, it can look like this:

    (defmacro short-lambda (x)
      `(lambda (%) ,x))

Even in this simple form, it can sweeten up Elisp a lot:

    (mapc #(put % 'disabled nil)
          '(upcase-region downcase-region narrow-to-region))

With the (less trivial) linked `short-lambda', the following is
possible:

    (cl-mapcar #(concat %1 " are " %2)
               '("roses" "violets")
               '("red" "blue"))

Here's a snippet from `org-mode':

    (mapcar (lambda (x)
              (and (member (car x) matchers) (nth 1 x)))
            org-latex-regexps)

Here's the sweetened code:

    (mapcar #(and (member (car %) matchers) (nth 1 %))
            org-latex-regexps)

As far as I know, only #("foo" ...) literal is already taken, so #(Z,
where Z is anything but a " is up for grabs, reader-wise.

I hope that you don't view this patch as malarkey. Saving a few chars
while typing and reading is a big deal to a lot of people.  And the
way I see it, this implementation doesn't cost much.

regards,
Oleh

[-- Attachment #2: 0001-Modify-reader-.-is-short-lambda.patch --]
[-- Type: text/x-patch, Size: 3436 bytes --]

From a8e0c5418598655bdfdda6d5cb541262a5575927 Mon Sep 17 00:00:00 2001
From: Oleh Krehel <ohwoeowho@gmail.com>
Date: Fri, 9 Jan 2015 08:33:07 +0100
Subject: [PATCH] Modify reader: #([^"]...) is (short-lambda ...)

* src/lread.c (read1): When "#(" is found, check if the next symbol is
  '"'. If it is, continue with the old string syntax. Otherwise, treat
  "#(...)" similar to a backquote, except the symbol name is
  `short-lambda' instead of `backquote'.

The indent is to allow to use "#(+ % %)" in place of
"(lambda (%) (+ % %))".

The simplest implementation:

    (defmacro short-lambda (structure)
      `(lambda (%) ,structure))

It could be easily extended to produce "(lambda (%1 %2) (+ %1 %2))"
from "#(+ %1 %2)".
---
 src/lread.c | 65 +++++++++++++++++++++++++++++++++++--------------------------
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/src/lread.c b/src/lread.c
index 3240524..905164f 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2671,34 +2671,42 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list)
 	}
       if (c == '(')
 	{
-	  Lisp_Object tmp;
-	  struct gcpro gcpro1;
-	  int ch;
-
-	  /* Read the string itself.  */
-	  tmp = read1 (readcharfun, &ch, 0);
-	  if (ch != 0 || !STRINGP (tmp))
-	    invalid_syntax ("#");
-	  GCPRO1 (tmp);
-	  /* Read the intervals and their properties.  */
-	  while (1)
-	    {
-	      Lisp_Object beg, end, plist;
-
-	      beg = read1 (readcharfun, &ch, 0);
-	      end = plist = Qnil;
-	      if (ch == ')')
-		break;
-	      if (ch == 0)
-		end = read1 (readcharfun, &ch, 0);
-	      if (ch == 0)
-		plist = read1 (readcharfun, &ch, 0);
-	      if (ch)
-		invalid_syntax ("Invalid string property list");
-	      Fset_text_properties (beg, end, plist, tmp);
-	    }
-	  UNGCPRO;
-	  return tmp;
+          int next_char = READCHAR;
+          UNREAD (next_char);
+          if (next_char == '"') {
+            Lisp_Object tmp;
+            struct gcpro gcpro1;
+            int ch;
+
+            /* Read the string itself.  */
+            tmp = read1 (readcharfun, &ch, 0);
+            if (ch != 0 || !STRINGP (tmp))
+              invalid_syntax ("#");
+            GCPRO1 (tmp);
+            /* Read the intervals and their properties.  */
+            while (1)
+              {
+                Lisp_Object beg, end, plist;
+
+                beg = read1 (readcharfun, &ch, 0);
+                end = plist = Qnil;
+                if (ch == ')')
+                  break;
+                if (ch == 0)
+                  end = read1 (readcharfun, &ch, 0);
+                if (ch == 0)
+                  plist = read1 (readcharfun, &ch, 0);
+                if (ch)
+                  invalid_syntax ("Invalid string property list");
+                Fset_text_properties (beg, end, plist, tmp);
+              }
+            UNGCPRO;
+            return tmp;
+          } else {
+            UNREAD(c);
+            Lisp_Object value = read0 (readcharfun);
+            return list2 (Qshort_lambda, value);
+          }
 	}
 
       /* #@NUMBER is used to skip NUMBER following bytes.
@@ -4731,6 +4739,7 @@ that are loaded before your customizations are read!  */);
   DEFSYM (Qcomma, ",");
   DEFSYM (Qcomma_at, ",@");
   DEFSYM (Qcomma_dot, ",.");
+  DEFSYM (Qshort_lambda, "short-lambda");
 
   DEFSYM (Qinhibit_file_name_operation, "inhibit-file-name-operation");
   DEFSYM (Qascii_character, "ascii-character");
-- 
1.8.4

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[samer]

Some parts of short-lambda's documentation is unclear to me. I have no 
experience with Clojure, so this is all from the perspective of someone 
new to short-lambda.

> 2. In the case when `%1' is the highest-ranking argument, it may be 
> abbreviated to `%'.

When '%1' is the highest-ranking argument, that means '%1' is the only 
argument, correct? I think this point will be more accessible if we 
don't rely on the reader knowing or correctly inferring what 
"highest-ranking" means, and use something along the lines of "when %1 
is the only argument" instead.

> 3. The lower-ranking arguments are auto-added, even if they are not 
> present in FORMS.

Auto-added to the list of arguments? Similar to my above point, it will 
be better if we can remove the dependency on "lower-ranking", and 
explain what we mean by that term (something like "all arguments with a 
smaller number than the argument with the largest number are included as 
part of the lambda's arguments, even if they do not appear in 
STRUCTURE").

Also, I don't know what FORMS means in this context, when the argument 
name is STRUCTURE.

I am new to emacs-devel, so I don't know how much weight my voice 
carries, but I support this being added to emacs core :)

-samer

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

Thanks for the input,

> Some parts of short-lambda's documentation is unclear to me. I have no
> experience with Clojure, so this is all from the perspective of someone new
> to short-lambda.
>
>> 2. In the case when `%1' is the highest-ranking argument, it may be
>> abbreviated to `%'.
>
>
> When '%1' is the highest-ranking argument, that means '%1' is the only
> argument, correct? I think this point will be more accessible if we don't
> rely on the reader knowing or correctly inferring what "highest-ranking"
> means, and use something along the lines of "when %1 is the only argument"
> instead.

Fixed with your suggestion. The point is not to mix % and e.g. %2.
Clojure allows this, for not particular reason.

>> 3. The lower-ranking arguments are auto-added, even if they are not
>> present in FORMS.
>
>
> Auto-added to the list of arguments? Similar to my above point, it will be
> better if we can remove the dependency on "lower-ranking", and explain what
> we mean by that term (something like "all arguments with a smaller number
> than the argument with the largest number are included as part of the
> lambda's arguments, even if they do not appear in STRUCTURE").

This means:

    (short-lambda (list %3)) => (lambda (%1 %2 %3) (list %3))


Oleh

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Artur Malabarba]

Firstly, I'd like to manifest my support for this feature.

Secondly, (even though this patch is obviously not complete, since it
still needs the actual macro) before it's done, don't forget to add a
ChangeLog entry with the commit.

Thirdly, you have a small typo in the commit message: "in[dt]ent".

2015-01-21 20:37 GMT-02:00 Oleh <ohwoeowho@gmail.com>:
> Thanks for the input,
>
>> Some parts of short-lambda's documentation is unclear to me. I have no
>> experience with Clojure, so this is all from the perspective of someone new
>> to short-lambda.
>>
>>> 2. In the case when `%1' is the highest-ranking argument, it may be
>>> abbreviated to `%'.
>>
>>
>> When '%1' is the highest-ranking argument, that means '%1' is the only
>> argument, correct? I think this point will be more accessible if we don't
>> rely on the reader knowing or correctly inferring what "highest-ranking"
>> means, and use something along the lines of "when %1 is the only argument"
>> instead.
>
> Fixed with your suggestion. The point is not to mix % and e.g. %2.
> Clojure allows this, for not particular reason.
>
>>> 3. The lower-ranking arguments are auto-added, even if they are not
>>> present in FORMS.
>>
>>
>> Auto-added to the list of arguments? Similar to my above point, it will be
>> better if we can remove the dependency on "lower-ranking", and explain what
>> we mean by that term (something like "all arguments with a smaller number
>> than the argument with the largest number are included as part of the
>> lambda's arguments, even if they do not appear in STRUCTURE").
>
> This means:
>
>     (short-lambda (list %3)) => (lambda (%1 %2 %3) (list %3))
>
>
> Oleh
>

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

> Firstly, I'd like to manifest my support for this feature.

Thanks.

> Secondly, (even though this patch is obviously not complete, since it
> still needs the actual macro) before it's done, don't forget to add a
> ChangeLog entry with the commit.

I'm just testing the waters here. I wasn't sure if a new reader macro
would be accepted. Also, I wouldn't know exactly where to put the Elisp
part, that's why it's still on github.

> Thirdly, you have a small typo in the commit message: "in[dt]ent".

Thanks again.

Oleh

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Artur Malabarba]

> Also, I wouldn't know exactly where to put the Elisp
> part, that's why it's still on github.

I'd say subr.el, as that's where lambda is defined. Since the macro
isn't “commonly used” yet, some might prefer for it to go into
subr-x.el.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Artur Malabarba]

On second thought. Because it's a reader macro, it would have to be
subr, since subr-x isn't necessarily loaded.

2015-01-21 22:54 GMT-02:00 Artur Malabarba <bruce.connor.am@gmail.com>:
>> Also, I wouldn't know exactly where to put the Elisp
>> part, that's why it's still on github.
>
> I'd say subr.el, as that's where lambda is defined. Since the macro
> isn't “commonly used” yet, some might prefer for it to go into
> subr-x.el.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On 01/21/2015 01:38 PM, Oleh wrote:
> Hi all,
> 
> This is my first attempt of modifying the C source of Emacs.
> The goal is to add a new reader syntax:
> 
>     #(foo bar) should translate to (short-lambda (foo bar))

Thanks, but I'd strongly prefer not to baking this syntax into the elisp
reader. IME, we tend not to use anonymous lambas enough to matter.
Clojure is idiomatically pure-functional; we're not.

I'd be more receptive to a generalized, CL-style reader-macro facility.
You could then use that to implement this syntax, but locally.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Drew Adams]

> > The goal is to add a new reader syntax:
> > #(foo bar) should translate to (short-lambda (foo bar))
> 
> Thanks, but I'd strongly prefer not to baking this syntax into the elisp
> reader. IME, we tend not to use anonymous lambas enough to matter.
> Clojure is idiomatically pure-functional; we're not.
> 
> I'd be more receptive to a generalized, CL-style reader-macro facility.
> You could then use that to implement this syntax, but locally.

+1 on all accounts, but especially for a CL-style reader-macro facility.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Lars Brinkhoff]

Drew Adams <drew.adams@oracle.com> writes:
>> I'd be more receptive to a generalized, CL-style reader-macro
>> facility.  You could then use that to implement this syntax, but
>> locally.
>
> +1 on all accounts, but especially for a CL-style reader-macro facility.

As always, I offer any part of my CL implementation for inclusion in Emacs.

In this case, I have the CL reader implemented in Emacs Lisp.  Of
course, some of it would have to be converted to C.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stephen J. Turnbull]

Daniel Colascione writes:
 > On 01/21/2015 01:38 PM, Oleh wrote:
 > > Hi all,
 > > 
 > > This is my first attempt of modifying the C source of Emacs.
 > > The goal is to add a new reader syntax:
 > > 
 > >     #(foo bar) should translate to (short-lambda (foo bar))
 > 
 > Thanks, but I'd strongly prefer not to baking this syntax into the elisp
 > reader.

XEmacs is -1 on this change for the same reasons Daniel gives.

I also don't like it because the convention is to use "#c" (where c is
some character) for new syntax (eg, XEmacs uses #r"" for "rawstring
syntax", where the benefit is huge because of the unreadability of
regexps in ordinary strings).

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

Hi Stephen,

>  > >
>  > > This is my first attempt of modifying the C source of Emacs.
>  > > The goal is to add a new reader syntax:
>  > >
>  > >     #(foo bar) should translate to (short-lambda (foo bar))
>  >
>  > Thanks, but I'd strongly prefer not to baking this syntax into the elisp
>  > reader.
>
> XEmacs is -1 on this change for the same reasons Daniel gives.
>
> I also don't like it because the convention is to use "#c" (where c is
> some character) for new syntax (eg, XEmacs uses #r"" for "rawstring
> syntax", where the benefit is huge because of the unreadability of
> regexps in ordinary strings).

Note that it only takes the "#([^\"]" spot. The "#c" convention is
completely untouched, unless "c" is "(".

Of course, I'm open to other variants, if this isn't accepted, maybe
"#l(foo bar)". The initial suggestion would be immediately familiar to
any Clojure programmer. Clojure is a bit more popular than Elisp,
judging by 8000 vs 3000 questions on Stack Overflow, and 25,000 vs
22,000 repositories on Github.

I'm also open to trying my hand at the "CL-style reader-macro
facility".  But this task would be much more complex than the simple
hack that I'm presenting here. So I really want to make sure that this
feature is wanted and will be accepted before I spend time on it.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[David Kastrup]

Oleh <ohwoeowho@gmail.com> writes:

> Hi Stephen,
>
>>  > >
>>  > > This is my first attempt of modifying the C source of Emacs.
>>  > > The goal is to add a new reader syntax:
>>  > >
>>  > >     #(foo bar) should translate to (short-lambda (foo bar))
>>  >
>>  > Thanks, but I'd strongly prefer not to baking this syntax into the elisp
>>  > reader.
>>
>> XEmacs is -1 on this change for the same reasons Daniel gives.
>>
>> I also don't like it because the convention is to use "#c" (where c is
>> some character) for new syntax (eg, XEmacs uses #r"" for "rawstring
>> syntax", where the benefit is huge because of the unreadability of
>> regexps in ordinary strings).
>
> Note that it only takes the "#([^\"]" spot. The "#c" convention is
> completely untouched, unless "c" is "(".
>
> Of course, I'm open to other variants, if this isn't accepted, maybe
> "#l(foo bar)". The initial suggestion would be immediately familiar to
> any Clojure programmer. Clojure is a bit more popular than Elisp,
> judging by 8000 vs 3000 questions on Stack Overflow,

Apparently we have better documentation and/or smarter users.

> and 25,000 vs 22,000 repositories on Github.

And Elisp is, after all, not a general-purpose scripting language but an
editor extension language.  At any rate, both of these numbers appear
vastly inflated.  I suspect that the "Elisp" category probably is
covered by any project that bothers with providing a major mode for
editing its files.

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Andreas Schwab]

Oleh <ohwoeowho@gmail.com> writes:

> Note that it only takes the "#([^\"]" spot. The "#c" convention is
> completely untouched, unless "c" is "(".

IMHO this is too close to the syntax for propertized strings.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

Hi Andreas,

>> Note that it only takes the "#([^\"]" spot. The "#c" convention is
>> completely untouched, unless "c" is "(".
>
> IMHO this is too close to the syntax for propertized strings.

This can also be seen as an advantage, this already is part of Emacs

    (read "#(\"foo\")")

All I'm doing is saying: if the first char of the string syntax isn't
", make it a
reader syntax for `short-lambda'.

Thus this reader syntax doesn't really tread other reader syntaxes.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[René Kyllingstad]

On Thursday, January 22, 2015, Daniel Colascione <dancol@dancol.org> wrote:
>
> On 01/21/2015 01:38 PM, Oleh wrote:
> > Hi all,
> >
> > This is my first attempt of modifying the C source of Emacs.
> > The goal is to add a new reader syntax:
> >
> >     #(foo bar) should translate to (short-lambda (foo bar))
>
> Thanks, but I'd strongly prefer not to baking this syntax into the elisp
> reader. IME, we tend not to use anonymous lambas enough to matter.

This syntax makes anonymous lambdas dramatically more attractive IMHO,
so I would not use current usage as an argument against it.


-- René

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[David Kastrup]

René Kyllingstad <listmailemacs@kyllingstad.com> writes:

> On Thursday, January 22, 2015, Daniel Colascione <dancol@dancol.org> wrote:
>>
>> On 01/21/2015 01:38 PM, Oleh wrote:
>> > Hi all,
>> >
>> > This is my first attempt of modifying the C source of Emacs.
>> > The goal is to add a new reader syntax:
>> >
>> >     #(foo bar) should translate to (short-lambda (foo bar))
>>
>> Thanks, but I'd strongly prefer not to baking this syntax into the elisp
>> reader. IME, we tend not to use anonymous lambas enough to matter.
>
> This syntax makes anonymous lambdas dramatically more attractive IMHO,
> so I would not use current usage as an argument against it.

Anonymous lambdas become considerably more useful once you have lexical
scoping.  The latter has not been around long enough to have had a major
impact on Elisp programming styles yet.

That does not mean that I am convinced we want or need short-lambda.

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

Hi David,

> Anonymous lambdas become considerably more useful once you have lexical
> scoping.  The latter has not been around long enough to have had a major
> impact on Elisp programming styles yet.
>
> That does not mean that I am convinced we want or need short-lambda.

The most popular library in MELPA, https://github.com/magnars/dash.el,
implements it (for a long time) like this:

    (--map (* it it) '(1 2 3))
    ;; => (1 4 9)

With my approach, it's:

    (mapcar #(* % %) '(1 2 3))
    ;; => (1 4 9)

I've grepped the useage of `--map' in all > 150 third party packages
that depend on `dash'.
I got 203 total results 60 different packages. This says a lot about
people wanting this feature for a long time.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

On 01/22/2015 01:27 AM, Oleh wrote:
>> Anonymous lambdas become considerably more useful once you have lexical
>> scoping.  The latter has not been around long enough to have had a major
>> impact on Elisp programming styles yet.
>>
>> That does not mean that I am convinced we want or need short-lambda.
> 
> The most popular library in MELPA, https://github.com/magnars/dash.el,
> implements it (for a long time) like this:
> 
>     (--map (* it it) '(1 2 3))
>     ;; => (1 4 9)
> 
> With my approach, it's:
> 
>     (mapcar #(* % %) '(1 2 3))
>     ;; => (1 4 9)

With idiomatic elisp, it's

  (mapcar (lambda (x) (* x x)) '(1 2 3))

Both alternatives above are more esoteric than the lambda form and are
approximately as wrong.  Note how the "lambda" is a prominent "I AM A
FUNCTION" signal.  I don't like the shorter forms, won't use them in my
code, and wouldn't rely on calling packages. I don't want to change the
Emacs reader to support this syntax.

That said, I would like CL-style reader macros. I can't stop you from
using reader macro support to implement your kind of function literal.
The proliferation of overly-clever code like the above two snippets is a
cost I am willing to bear for having reader macros macros.

> I've grepped the useage of `--map' in all > 150 third party packages
> that depend on `dash'.
> I got 203 total results 60 different packages. This says a lot about
> people wanting this feature for a long time.

No it doesn't: you didn't provide a baseline. Allow me.

~/edev/trunk/lisp
$ ppgrep -w '(lambda' | wc -l
6834


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>> I've grepped the useage of `--map' in all > 150 third party packages
>> that depend on `dash'.
>> I got 203 total results 60 different packages. This says a lot about
>> people wanting this feature for a long time.
>
> No it doesn't: you didn't provide a baseline. Allow me.
>
> ~/edev/trunk/lisp
> $ ppgrep -w '(lambda' | wc -l
> 6834

Now, you're bending it the other way:)

Do note, that we're comparing `lambda', which was part of core Emacs
forever and ships with each Emacs,
to a library concieved 2 years ago, and to use which, the other
package writers have
to go out of their way (I, for one, try not to depend on third party
packages unless I have to).

So yes, it's 6834 vs 200, but consider the circumstances.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

On 01/22/2015 01:45 AM, Oleh wrote:
>>> I've grepped the useage of `--map' in all > 150 third party packages
>>> that depend on `dash'.
>>> I got 203 total results 60 different packages. This says a lot about
>>> people wanting this feature for a long time.
>>
>> No it doesn't: you didn't provide a baseline. Allow me.
>>
>> ~/edev/trunk/lisp
>> $ ppgrep -w '(lambda' | wc -l
>> 6834
> 
> Now, you're bending it the other way:)
> 
> Do note, that we're comparing `lambda', which was part of core Emacs
> forever and ships with each Emacs,

Speaking of things that ship with Emacs: have you tried
prettify-symbols-mode?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

> Speaking of things that ship with Emacs: have you tried
> prettify-symbols-mode?
>

No need, I've had it for years with the approach that I describe here:
http://oremacs.com/2015/01/11/pretty-elisp-regex/

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

On 01/22/2015 01:52 AM, Oleh wrote:
>> Speaking of things that ship with Emacs: have you tried
>> prettify-symbols-mode?
>>
> 
> No need, I've had it for years with the approach that I describe here:
> http://oremacs.com/2015/01/11/pretty-elisp-regex/

Sure. My point is that existence of prettify-symbols-mode and equivalent
is another argument against the creation of a shorter-than-lambda
function literal syntax.

(By the way: the idea of a mode that hides backslashes in string
literals scares me. I'd much rather just use rx.)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

> Sure. My point is that existence of prettify-symbols-mode and equivalent
> is another argument against the creation of a shorter-than-lambda
> function literal syntax.

Note that this isn't just a lame

    (defalias 'λ 'lambda)

we're talking about here. `short-lambda' takes away a *whole* paren
nesting level, which can be a lot, when there's only two (and there
usually is).

It makes these one-line lambdas more pleasant to look at, they appear
as simple atoms in the code, instead of structures, as they would:

    (let ((foo (lambda (x) (+ x x)))
          (bar #(+ % %)))
      (list (funcall foo 5)
            (funcall bar 6)))

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Ivan Andrus]

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Jan 22, 2015, at 3:05 AM, Oleh <ohwoeowho@gmail.com> wrote:

Sure. My point is that existence of prettify-symbols-mode and equivalent
is another argument against the creation of a shorter-than-lambda
function literal syntax.


Note that this isn't just a lame

  (defalias 'λ 'lambda)

we're talking about here. `short-lambda' takes away a *whole* paren
nesting level, which can be a lot, when there's only two (and there
usually is).


FWIW, if you change short-lambda to be

(defmacro short-lambda (&rest structure)
 ...)

then short-lambda can get rid of the extra level of parens.  Though I have
to admit that

#(+ % %)

is probably easier to read than

(λ + % %)

I’m personally slightly in favor of this feature (and more in favor of
reader macros).  But everything we add to Emacs lisp is something must also
be added to Guile before we can get EmacsGuile which I would also like. :)

I have my own interactive-lambda macro that creates interactive lambdas for
use in keybindings and such.  It seems that making the lambdas interactive
is a very important feature for the use cases I have for lambdas in Emacs.
I also have an (inaccurately named) add-lambda-to-hook macro that creates a
_named_ function and adds it to a hook.  This prevents it from being double
added and allows updating the "lambda".  IOW I'm not sure a single
mechanism can handle all use cases satisfactorily.

-Ivan

[-- Attachment #2: Type: text/html, Size: 1759 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Leo Liu]

On 2015-01-22 17:38 +0800, Daniel Colascione wrote:
> With idiomatic elisp, it's
>
>   (mapcar (lambda (x) (* x x)) '(1 2 3))
>
> Both alternatives above are more esoteric than the lambda form and are
> approximately as wrong.  Note how the "lambda" is a prominent "I AM A
> FUNCTION" signal.  I don't like the shorter forms, won't use them in my
> code, and wouldn't rely on calling packages. I don't want to change the
> Emacs reader to support this syntax.

I must agree with this point. Code is written often once and read many
many times for many decades in emacs. Clojure's syntax is noisier than
most lisps we love.

Leo

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Lars Ingebrigtsen]

Daniel Colascione <dancol@dancol.org> writes:

>> The most popular library in MELPA, https://github.com/magnars/dash.el,
>> implements it (for a long time) like this:
>> 
>>     (--map (* it it) '(1 2 3))
>>     ;; => (1 4 9)
>> 
>> With my approach, it's:
>> 
>>     (mapcar #(* % %) '(1 2 3))
>>     ;; => (1 4 9)
>
> With idiomatic elisp, it's
>
>   (mapcar (lambda (x) (* x x)) '(1 2 3))
>
> Both alternatives above are more esoteric than the lambda form and are
> approximately as wrong.  Note how the "lambda" is a prominent "I AM A
> FUNCTION" signal.

I don't like it either, but perhaps it's a good idea anyway?

1) I really like the way that Lisp has a culture of making explicit
bindings.  Naming variables helps a lot with reading comprehension,
which is a pretty important thing.

In these toy examples it doesn't make much difference, but that's not
how real code looks like.  In real code you have ten-line lambdas with
the "%" appearing on the second-to-last line, and you will have
forgotten what that "%" refers to when you reach that line.

And the forms are awfully kludgey, since they don't really nest that
well.

2) The Kids These Days really love this way of writing code.  I mean,
kids have always loved write-only obfuscatory code, but they seem to
have really glommed on to this idiom of implicit parameters in
closures.

Perhaps part of that is just that there are so many programmers forced
to work in the Java industry, and they only have the choice of working
with the dreary drudgery of actual Java code, the incomprehensibility of
Scala, and the (in comparison) sanity of Clojure.  And the Clojure peeps
really like that style, it seems.

So to make Emacs Lisp more attractive to the incoming locust of Clojure
programmers, perhaps we should accommodate that by adding these forms?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stephen J. Turnbull]

Oleh writes:

 > The most popular library in MELPA, https://github.com/magnars/dash.el,
 > implements it (for a long time) like this:
 > 
 >     (--map (* it it) '(1 2 3))
 >     ;; => (1 4 9)
 > 
 > With my approach, it's:
 > 
 >     (mapcar #(* % %) '(1 2 3))
 >     ;; => (1 4 9)

That looks almost like Perl!  Now I'm -2.  Just require dash.

Personally, I don't see a huge advantage to anonymous functions
anyway, not even in an interactive repl, and would surely spell it
either

    (defun square (x) (* x x))
    (mapcar #'square '(1 2 3))

or

    (labels ((square (x) (* x x)))
      (mapcar #'square '(1 2 3)))

in a library.  (Does Emacs have `labels'?  If not, `flet'.)  Tastes
vary, of course, but to me the existence of dash really looks like a
good argument for those with your tastes to use dash, not to add this
to Emacs.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[David Kastrup]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Oleh writes:
>
>  > The most popular library in MELPA, https://github.com/magnars/dash.el,
>  > implements it (for a long time) like this:
>  > 
>  >     (--map (* it it) '(1 2 3))
>  >     ;; => (1 4 9)
>  > 
>  > With my approach, it's:
>  > 
>  >     (mapcar #(* % %) '(1 2 3))
>  >     ;; => (1 4 9)
>
> That looks almost like Perl!  Now I'm -2.  Just require dash.
>
> Personally, I don't see a huge advantage to anonymous functions
> anyway, not even in an interactive repl,

They are useful for calculated bindings.  Context-sensitive mouse-overs
or active links, regular bindings (I am currently working on some
private project involving keybindings to keys on an accordion keyboard,
and little surprisingly those are all different but all of the same
kind).

Stuff like that.

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stephen J. Turnbull]

David Kastrup writes:
 > "Stephen J. Turnbull" <stephen@xemacs.org> writes:

 > > Personally, I don't see a huge advantage to anonymous functions
 > > anyway, not even in an interactive repl,
 > 
 > They are useful for calculated bindings.

Of course.[1]  I didn't mean anonymous functions were useless, I meant
in the contexts so far mentioned.

Footnotes: 
[1]  ISTM that that goes without saying, given that Lisp having data
and code representations using the same syntax is advertised as an
advantage.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

> Footnotes:
> [1]  ISTM that that goes without saying, given that Lisp having data
> and code representations using the same syntax is advertised as an
> advantage.

I don't see a problem:

    (list
     (cadr #(+ % %))
     (cadr #(+ % %))
     (caddr #(+ % %))
     (caddr #(+ % %)))
    ;; => ((%) (%) (+ % %) (+ % %))

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stephen J. Turnbull]

Oleh writes:
 > > Footnotes:
 > > [1]  ISTM that that goes without saying, given that Lisp having data
 > > and code representations using the same syntax is advertised as an
 > > advantage.
 > 
 > I don't see a problem:

Not everything is a problem.  I understand that "#(fubar indeed!)"
is reader syntax and doesn't affect internal representation of the
lambdas.  That was a comment to David that (as often happens in his
posts) he is taking the literal meaning of metaphorical or elliptical
expressions too seriously.  Metaprogramming is the soul of Lisp, I
know that and he knows that I know that.  We disagree so violently
because we disagree so little. ;-)[1]

Re this sprinkling of bitter herbs: I just don't like the syntax (in
general I'm not a fan of anatropic syntax in Lisp), and don't want to
support use of it in the educational sense of support or in core
maintenance in XEmacs.  I don't expect to convince you, it's a matter
of taste.  My likes and dislikes matter to more than me because I do a
*lot* of support, and the more magic there is in the world the harder
it is to explain to users who believe in magic that under the hood
it's just a lambda.  I think this

(car #(fubAr quux)) => 'lambda

would be *very* surprising to most users.  That kind of computation is
what functions are for.


Footnotes: 
[1]  Not funny, actually, but I'm too old to change and respect David
too much to ask him to change.  I even kinda like him as he is. :-)

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>  > The most popular library in MELPA, https://github.com/magnars/dash.el,
>  > implements it (for a long time) like this:
>  >
>  >     (--map (* it it) '(1 2 3))
>  >     ;; => (1 4 9)
>  >
>  > With my approach, it's:
>  >
>  >     (mapcar #(* % %) '(1 2 3))
>  >     ;; => (1 4 9)
>
> That looks almost like Perl!  Now I'm -2.  Just require dash.

How is `dash' better? `--map' is a macro:

    (defmacro --map (form list)
      "Anaphoric form of `-map'."
      (declare (debug (form form)))
      `(mapcar (lambda (it) ,form) ,list))

`dash' also gives other ~40 macros that look like this, littered all
over the code in the MELPA, so it's impossible to go on without
understanding what `dash' does.

On the other hand, `mapcar' is a C function. It and all other
functions can use `short-lambda' instead of being reimplemented as
macros on a case-per-case basis by `dash'.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[David Kastrup]

Oleh <ohwoeowho@gmail.com> writes:

>>  > The most popular library in MELPA, https://github.com/magnars/dash.el,
>>  > implements it (for a long time) like this:
>>  >
>>  >     (--map (* it it) '(1 2 3))
>>  >     ;; => (1 4 9)
>>  >
>>  > With my approach, it's:
>>  >
>>  >     (mapcar #(* % %) '(1 2 3))
>>  >     ;; => (1 4 9)
>>
>> That looks almost like Perl!  Now I'm -2.  Just require dash.
>
> How is `dash' better? `--map' is a macro:
>
>     (defmacro --map (form list)
>       "Anaphoric form of `-map'."
>       (declare (debug (form form)))
>       `(mapcar (lambda (it) ,form) ,list))
>
> `dash' also gives other ~40 macros that look like this, littered all
> over the code in the MELPA, so it's impossible to go on without
> understanding what `dash' does.
>
> On the other hand, `mapcar' is a C function. It and all other
> functions can use `short-lambda' instead of being reimplemented as
> macros on a case-per-case basis by `dash'.

So use cl-loop.  Has the advantage of being _both_ concise as well as
efficient after compilation since Emacs Lisp is not really fast at
function calls.

(cl-loop for i from 1 to 3 collect (* i i))

Or (cl-loop for i in '(1 2 3) collect (* i i))

The code cl-loop creates is usually quite faster than any of the map*
functions.  I haven't checked with lexical bindings though: it is
conceivable that the anonymous lambda cost goes down for them, but so
does the variable-binding cost for cl-loop.

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>>>  > The most popular library in MELPA, https://github.com/magnars/dash.el,
>>>  > implements it (for a long time) like this:
>>>  >
>>>  >     (--map (* it it) '(1 2 3))
>>>  >     ;; => (1 4 9)
>>>  >
>>>  > With my approach, it's:
>>>  >
>>>  >     (mapcar #(* % %) '(1 2 3))
>>>  >     ;; => (1 4 9)
>>>
>>> That looks almost like Perl!  Now I'm -2.  Just require dash.
>>
>> How is `dash' better? `--map' is a macro:
>>
>>     (defmacro --map (form list)
>>       "Anaphoric form of `-map'."
>>       (declare (debug (form form)))
>>       `(mapcar (lambda (it) ,form) ,list))
>>
>> `dash' also gives other ~40 macros that look like this, littered all
>> over the code in the MELPA, so it's impossible to go on without
>> understanding what `dash' does.
>>
>> On the other hand, `mapcar' is a C function. It and all other
>> functions can use `short-lambda' instead of being reimplemented as
>> macros on a case-per-case basis by `dash'.
>
> So use cl-loop.  Has the advantage of being _both_ concise as well as
> efficient after compilation since Emacs Lisp is not really fast at
> function calls.
>
> (cl-loop for i from 1 to 3 collect (* i i))
>
> Or (cl-loop for i in '(1 2 3) collect (* i i))
>
> The code cl-loop creates is usually quite faster than any of the map*
> functions.  I haven't checked with lexical bindings though: it is
> conceivable that the anonymous lambda cost goes down for them, but so
> does the variable-binding cost for cl-loop.

If it were up to me, I'd use `cl-loop' everywhere. But I'm not in a
vacuum: I use and monitor many packages. And I can't just tell 60
random people: "Dont use `dash', that approach is silly, use `cl-loop'
instead". What I can do though, is to provide an alternative for core
Emacs with no disadvantages of the anaphoric macros of `dash'.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Tassilo Horn]

Oleh <ohwoeowho@gmail.com> writes:

>>  > The most popular library in MELPA, https://github.com/magnars/dash.el,
>>  > implements it (for a long time) like this:
>>  >
>>  >     (--map (* it it) '(1 2 3))
>>  >     ;; => (1 4 9)
>>  >
>>  > With my approach, it's:
>>  >
>>  >     (mapcar #(* % %) '(1 2 3))
>>  >     ;; => (1 4 9)
>>
>> That looks almost like Perl!  Now I'm -2.  Just require dash.
>
> How is `dash' better? `--map' is a macro:
>
>     (defmacro --map (form list)
>       "Anaphoric form of `-map'."
>       (declare (debug (form form)))
>       `(mapcar (lambda (it) ,form) ,list))
>
> `dash' also gives other ~40 macros that look like this, littered all
> over the code in the MELPA, so it's impossible to go on without
> understanding what `dash' does.

FWIW, I favor your Clojure-like syntax over anaphoric macros.  And one
benefit is that you're not restricted to one list to map over as in
--map.  E.g., your approach works out of the box with

  (cl-mapcar #(- %5 %4 %3 %2 %1) list1 list2 list3 list4 list5)

for which there is no dash equivalent.  Of course, --map could be
extended to create args (it1 ... itN) if more than one list is given.

BTW, do you also support %& to declare that the lambda has a &rest arg
so that you can do

  (apply #'cl-mapcar #(apply #'- (reverse %&)) list-of-lists)

?

So basically I like that syntax (or maybe #l(...) or #fn(...)) and would
consider using it where it makes sense.  But as others already
mentioned, those places are much fewer than in an almost purely
functional language like Clojure.

Bye,
Tassilo

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>> How is `dash' better? `--map' is a macro:
>>
>>     (defmacro --map (form list)
>>       "Anaphoric form of `-map'."
>>       (declare (debug (form form)))
>>       `(mapcar (lambda (it) ,form) ,list))
>>
>> `dash' also gives other ~40 macros that look like this, littered all
>> over the code in the MELPA, so it's impossible to go on without
>> understanding what `dash' does.
>
> FWIW, I favor your Clojure-like syntax over anaphoric macros.  And one
> benefit is that you're not restricted to one list to map over as in
> --map.  E.g., your approach works out of the box with
>
>   (cl-mapcar #(- %5 %4 %3 %2 %1) list1 list2 list3 list4 list5)
>
> for which there is no dash equivalent.  Of course, --map could be
> extended to create args (it1 ... itN) if more than one list is given.
>
> BTW, do you also support %& to declare that the lambda has a &rest arg
> so that you can do
>
>   (apply #'cl-mapcar #(apply #'- (reverse %&)) list-of-lists)
>
> ?

Yes, this is works:

    (apply #'cl-mapcar #(apply #'- (reverse %&))
           '((2 4 10)
             (4 5 6)))
    ;; => (2 1 -4)

shortly:

    (short-lambda (apply (function -) (reverse %&)))
    ;; => (lambda (&rest %&) (apply (function -) (reverse %&)))

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stephen J. Turnbull]

Oleh writes:

 > How is `dash' better?

It's not in XEmacs core, so I don't have to look at it.

The proposed "short-lambda" is pure sugar and adds zero expressiveness
to the language.  Furthermore, in Emacsen it would be subject to
substantial abuse (eg, in hooks where anonymous functions are a bad
idea).

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>  > How is `dash' better?
>
> It's not in XEmacs core, so I don't have to look at it.

Still, I would not mark it as "Problem solved".  For many people,
Emacs is unusable without third party packages, where solutions to
like `dash' surface to problems that could be better solved in the
core.

> The proposed "short-lambda" is pure sugar and adds zero expressiveness
> to the language.  Furthermore, in Emacsen it would be subject to
> substantial abuse (eg, in hooks where anonymous functions are a bad
> idea).

Of course it's pure sugar. It's short-lambda's sole intention.

But isn't the backquote also pure sugar?  And, believe me, I'm abusing
the hell out of hooks and backquote, just becuase I have the option.
That doesn't mean that anyone would let any of that nonsense through
to the core. And it doesn't mean that adding backquote to the core was
a bad decision.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stephen J. Turnbull]

Oleh writes:
 > >  > How is `dash' better?
 > >
 > > It's not in XEmacs core, so I don't have to look at it.
 > 
 > Still, I would not mark it as "Problem solved".  For many people,
 > Emacs is unusable without third party packages, where solutions to
 > like `dash' surface to problems that could be better solved in the
 > core.

I disagree that it's a problem, and I disagree that it's a better
solution even if my users were to say it's a problem.

 > > The proposed "short-lambda" is pure sugar and adds zero expressiveness
 > > to the language.  Furthermore, in Emacsen it would be subject to
 > > substantial abuse (eg, in hooks where anonymous functions are a bad
 > > idea).
 > 
 > Of course it's pure sugar. It's short-lambda's sole intention.
 > 
 > But isn't the backquote also pure sugar?

Yes, in some sense, but in another, it is not: backquote adds a
template language to Lisp, which in combination with macros is very
expressive.  Short-lambda just makes it easier to write obscure code
concisely.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Artur Malabarba]

> The proposed "short-lambda" is pure sugar and adds zero expressiveness
> to the language.  Furthermore, in Emacsen it would be subject to
> substantial abuse (eg, in hooks where anonymous functions are a bad
> idea).

Are they more subject than a full lambda?

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stephen J. Turnbull]

Artur Malabarba writes:

 > > The proposed "short-lambda" is pure sugar and adds zero expressiveness
 > > to the language.  Furthermore, in Emacsen it would be subject to
 > > substantial abuse (eg, in hooks where anonymous functions are a bad
 > > idea).
 > 
 > Are they more subject than a full lambda?

Technically, no, psychologically, maybe.  Certainly no less.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Phillip Lord]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Oleh writes:
>
>  > The most popular library in MELPA, https://github.com/magnars/dash.el,
>  > implements it (for a long time) like this:
>  > 
>  >     (--map (* it it) '(1 2 3))
>  >     ;; => (1 4 9)
>  > 
>  > With my approach, it's:
>  > 
>  >     (mapcar #(* % %) '(1 2 3))
>  >     ;; => (1 4 9)
>
> That looks almost like Perl!  Now I'm -2.  Just require dash.


It is an open question with clojure as well how often to use this syntax
as opposed to Clojure's lambda. I tend to prefer the lambda syntax
because (ironically) it is capable to being de-anonymised; so all of
these do the same thing:

#(%)
(fn [y] y)
(fn x [y] y)

but the last one gives easier to read stack traces. In practice, though,
the shorthand syntax does not tend to produce overly perl-like code; it
is a self-limiting syntax, since it does not nest.

My first impression of Clojure was that it had too much syntactic-sugar,
but having used it a lot now, I tend to appreciate it more. I miss the
explicit map notation most of all in elisp.

Phil

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[René Kyllingstad]

On Thu, Jan 22, 2015 at 10:17 AM, David Kastrup <dak@gnu.org> wrote:
> That does not mean that I am convinced we want or need short-lambda.

Both C++ and Java have "recently" added a succinct syntax for their equivalents.

Given the amount of work it is to add features to either platform,
quite a few people
deemed it useful there.

At least most peoples .emacs will look a bit tidier with a succinct
anonymous lambda
as an argument to add-hook :)

The syntax proposed by OP is the neatest so far, but any succinct
syntax will probably be ok.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

On 01/22/2015 01:35 AM, René Kyllingstad wrote:
> On Thu, Jan 22, 2015 at 10:17 AM, David Kastrup <dak@gnu.org> wrote:
>> That does not mean that I am convinced we want or need short-lambda.
> 
> Both C++ and Java have "recently" added a succinct syntax for their equivalents.

They have, although Boost.Lambda is arguable even terser than what ended
up in the standard.  What makes the C++ and Java improvements different
is that the alternatives available in the old dialects of C++ and Java
were _far_ more verbose than the new syntax, so the relative gain was
larger than we'd see with the syntax proposed in this thread.  lambda is
terse enough already that we don't need a new, even terser syntax.

A better comparison is ES6 JavaScript's new short function syntax, which
replaces something like this:

  function(arg) { return foo(arg); }

with

  arg => foo(arg)

That's still a much bigger relative improvement than we'd get from
compressing the lambda symbol down to nothing.  ES6 arrows are also
this-capturing, which is a much-needed improvement in that language.  We
have no such problem.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[David Kastrup]

René Kyllingstad <Rene@Kyllingstad.com> writes:

> On Thu, Jan 22, 2015 at 10:17 AM, David Kastrup <dak@gnu.org> wrote:
>> That does not mean that I am convinced we want or need short-lambda.
>
> Both C++ and Java have "recently" added a succinct syntax for their equivalents.
>
> Given the amount of work it is to add features to either platform,
> quite a few people
> deemed it useful there.
>
> At least most peoples .emacs will look a bit tidier with a succinct
> anonymous lambda
> as an argument to add-hook :)

You are aware that using add-hook with ad-hoc functions is a bad idea
since it may mean that you add the same functionality several times in
case the add-hook is executed multiple times?

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On 01/22/2015 01:49 AM, David Kastrup wrote:
> René Kyllingstad <Rene@Kyllingstad.com> writes:
> 
>> On Thu, Jan 22, 2015 at 10:17 AM, David Kastrup <dak@gnu.org> wrote:
>>> That does not mean that I am convinced we want or need short-lambda.
>>
>> Both C++ and Java have "recently" added a succinct syntax for their equivalents.
>>
>> Given the amount of work it is to add features to either platform,
>> quite a few people
>> deemed it useful there.
>>
>> At least most peoples .emacs will look a bit tidier with a succinct
>> anonymous lambda
>> as an argument to add-hook :)
> 
> You are aware that using add-hook with ad-hoc functions is a bad idea
> since it may mean that you add the same functionality several times in
> case the add-hook is executed multiple times?

I occasionally use defun for that:

  (add-hook 'some-hook (defun foo () (bar))

This way, no matter how many times we evaluate the form, we install only
one function.  It's usually clearer to just define the function out of
line though.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[David Kastrup]

René Kyllingstad <Rene@Kyllingstad.com> writes:

> On Thu, Jan 22, 2015 at 10:17 AM, David Kastrup <dak@gnu.org> wrote:
>> That does not mean that I am convinced we want or need short-lambda.
>
> Both C++ and Java have "recently" added a succinct syntax for their
> equivalents.

Are you trying to argue for or against your proposal?  We are talking
about Emacs Lisp here, a small language dialect that has been very
conservative about assimilating Common Lisp features, with Common Lisp
being a humongous committee-driven language like C++ and Java.

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Artur Malabarba]

> Thanks, but I'd strongly prefer not to baking this syntax into the elisp
> reader. IME, we tend not to use anonymous lambas enough to matter.
> Clojure is idiomatically pure-functional; we're not.

It's not much about how pure-functional the language is, it's about
how useful the feature would be.
Later on this thread you report over 6800 lambdas in the code. How
many would have been enough?

> I'd be more receptive to a generalized, CL-style reader-macro facility.
> You could then use that to implement this syntax, but locally.

I have nothing against implementing this feature, but it would be more
complicated to implement and probably end up being less used than the
suggested feature. Why not have a shorthand lambda as well?

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Phillip Lord]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> Thanks, but I'd strongly prefer not to baking this syntax into the elisp
>> reader. IME, we tend not to use anonymous lambas enough to matter.
>> Clojure is idiomatically pure-functional; we're not.
>
> It's not much about how pure-functional the language is, it's about
> how useful the feature would be.
> Later on this thread you report over 6800 lambdas in the code. How
> many would have been enough?
>
>> I'd be more receptive to a generalized, CL-style reader-macro facility.
>> You could then use that to implement this syntax, but locally.
>
> I have nothing against implementing this feature, but it would be more
> complicated to implement and probably end up being less used than the
> suggested feature. Why not have a shorthand lambda as well?


The prospect of 30 implementations of shorthand lambdas does not fill be
with joy either. If there were reader macros then the question as to
whether to implement short hand lambdas would still come up.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

On 01/22/2015 04:46 AM, Phillip Lord wrote:
> Artur Malabarba <bruce.connor.am@gmail.com> writes:
> 
>>> Thanks, but I'd strongly prefer not to baking this syntax into the elisp
>>> reader. IME, we tend not to use anonymous lambas enough to matter.
>>> Clojure is idiomatically pure-functional; we're not.
>>
>> It's not much about how pure-functional the language is, it's about
>> how useful the feature would be.
>> Later on this thread you report over 6800 lambdas in the code. How
>> many would have been enough?
>>
>>> I'd be more receptive to a generalized, CL-style reader-macro facility.
>>> You could then use that to implement this syntax, but locally.
>>
>> I have nothing against implementing this feature, but it would be more
>> complicated to implement and probably end up being less used than the
>> suggested feature. Why not have a shorthand lambda as well?
> 
> 
> The prospect of 30 implementations of shorthand lambdas does not fill be
> with joy either. If there were reader macros then the question as to
> whether to implement short hand lambdas would still come up.

And the people who care for this shorthand syntax can do their
experiments out-of-tree, where they belong. It's unlikely that short
lambda syntax will ever make it into the Emacs core.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>>>> I'd be more receptive to a generalized, CL-style reader-macro facility.
>>>> You could then use that to implement this syntax, but locally.
>>>
>>> I have nothing against implementing this feature, but it would be more
>>> complicated to implement and probably end up being less used than the
>>> suggested feature. Why not have a shorthand lambda as well?
>>
>>
>> The prospect of 30 implementations of shorthand lambdas does not fill be
>> with joy either. If there were reader macros then the question as to
>> whether to implement short hand lambdas would still come up.
>
> And the people who care for this shorthand syntax can do their
> experiments out-of-tree, where they belong. It's unlikely that short
> lambda syntax will ever make it into the Emacs core.

Why so harsh?

Was there a debate when `rx' made it to the Emacs core?  It's an
alternative syntax (which actually I still haven't learned, because,
unlike `short-lambda', `rx' is actually hard to learn) for a string
regex. There's nothing like it in other PLs, unlike the string
regexes, which most of PLs feature.

So how do I deal with `rx' when I encounter one?

    with C-x C-e

So how can you deal with #(* % 2) when you encounter one?

    with C-x C-e: returns "(lambda (%) (* % 2))"

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I have nothing against adding new features to Emacs Lisp,
but I think that better handling of variable-width text
and ability to justify it with partial-width spaces
would do a lot more good for _users_ of Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I have nothing against adding new features to Emacs Lisp,
> but I think that better handling of variable-width text
> and ability to justify it with partial-width spaces
> would do a lot more good for _users_ of Emacs.

I don't think that work on those features would be in competition:
different people are interested both in programming and in using those.

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I have nothing against adding new features to Emacs Lisp,
  > > but I think that better handling of variable-width text
  > > and ability to justify it with partial-width spaces
  > > would do a lot more good for _users_ of Emacs.

  > I don't think that work on those features would be in competition:
  > different people are interested both in programming and in using those.

I expect that any project that gets pushed on the list
will draw interest from some people who might equally well have got
excited about a different project.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 917 bytes --]

() Richard Stallman <rms@gnu.org>
() Fri, 23 Jan 2015 20:09:59 -0500

   I expect that any project that gets pushed on the list will
   draw interest from some people who might equally well have
   got excited about a different project.

I'll take this as my cue, i suppose.  Public apology: In 2002
(or thereabouts), i volunteered to add these features, and made
an experimental change in ‘current-column’ to return a float,
with the intent of continuing "inwards" to convert the simple
counting to an iterator-based summation.  Then, i stopped
hacking (at column 0, so to speak), distracted by Guile (et al)
and other life events.  I lost my way and am sorry for that.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Eli Zaretskii]

> Date: Thu, 22 Jan 2015 17:10:33 -0500
> From: Richard Stallman <rms@gnu.org>
> Cc: phillip.lord@newcastle.ac.uk, dancol@dancol.org, bruce.connor.am@gmail.com,
> 	emacs-devel@gnu.org
> 
> I think that better handling of variable-width text and ability to
> justify it with partial-width spaces would do a lot more good for
> _users_ of Emacs.

Could you or someone else post a list of tasks towards these goals?  I
think this could be a good starting point for working on that.  I
don't think we have such a list at this time, but if I'm wrong, please
point me at that list.

Thanks.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stefan Monnier]

>     #(foo bar) should translate to (short-lambda (foo bar))

Hmm...

Not completely sure where I stand on this.
A few notes:
- I like the generality of CL reader macros.
- But extending elisp-mode to understand what's going on (and "do the
  right thing") with each new reader macro is not easy.
  So I'm currently against addition of CL style reader macros.
  In this sense your #(...) proposal is not too bad because the new
  syntax is largely compatible with what we have already (e.g. the (...)
  part is parsed in the normal way).
- In "(lambda (x) (foo bar))" the main problem for me is the visual length,
  so I use pretty-symbols-mode to make it look like (λ (x) (foo bar)).
  #(foo bar) is still shorter, tho, so I like this.
- I'm a functional programmer at heart, so I like making higher-order
  functions more accessible.
- But the current Elisp implementation is not good at handling function
  calls efficiently, so offering a very short syntax like #(foo bar) is
  kind of lying to the programmer.
- Elisp has the particularity that it's used by a very large number of
  people who don't actually know/understand the language, and will never
  really learn it.  OT1H (add-hook 'foo-mode-hook #(define-key toto titi))
  looks simpler, but OTOH having more equivalent syntaxes leads to more
  confusion for beginners.

So I'm not dead set against it, but I'm not really sure it'd be an
improvement either.

Of course, your proposal has 2 parts:
- the #(...) reader syntax.
- the new macro.
They work together but can also be used separately.  E.g. we could have
just the macro and write things like (mapcar (code (+ % 1)) list).
And we could have just the #(...) syntax and give it any meaning we like.


        Stefan

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>>     #(foo bar) should translate to (short-lambda (foo bar))
>
> Hmm...
>
> Not completely sure where I stand on this.

Thanks for the consideration in any case. And I'm glad that I asked
this, even if it doesn't lead to a change.

> A few notes:
> - I like the generality of CL reader macros.
> - But extending elisp-mode to understand what's going on (and "do the
>   right thing") with each new reader macro is not easy.
>   So I'm currently against addition of CL style reader macros.

This is good to know. What initially pushed me into this was seeing
code that uses `dash.el' and not understanding what `dash.el' does,
since it provides not just plain functions, but second order functions
that control the flow of the program. That meant that I had to learn
it whether I wanted to or not, even if I'm not using it in any of my
packages.

I'm afraid that making CL style macros available to the public would
lead to more 3rd party extensions defining control structures used by
other 3rd party extensions. My opinion is that only the core should be
allowed to do that. Or at least the 3rd party control flow structures
should not propagate.

But people want sugar, and that's what `dash.el' gives to them. My
#(...) could be a quick fix for that.

>   In this sense your #(...) proposal is not too bad because the new
>   syntax is largely compatible with what we have already (e.g. the (...)
>   part is parsed in the normal way).

Am I right in the assumption that only current #(...) syntax is that
of #("foo" ...)? Nothing other than propertized strings uses it?

> - In "(lambda (x) (foo bar))" the main problem for me is the visual length,
>   so I use pretty-symbols-mode to make it look like (λ (x) (foo bar)).
>   #(foo bar) is still shorter, tho, so I like this.

For some people, removing one set of parens could be more important
than shortening `lambda' to `λ'.  I like either way.

> - I'm a functional programmer at heart, so I like making higher-order
>   functions more accessible.
> - But the current Elisp implementation is not good at handling function
>   calls efficiently, so offering a very short syntax like #(foo bar) is
>   kind of lying to the programmer.

Note that #(foo %) is open to optimizations: it doesn't have to be
exactly (lambda (%) (foo %)), it just has to behave like it. I'm not
sure if that helps.

> - Elisp has the particularity that it's used by a very large number of
>   people who don't actually know/understand the language, and will never
>   really learn it.  OT1H (add-hook 'foo-mode-hook #(define-key toto titi))
>   looks simpler, but OTOH having more equivalent syntaxes leads to more
>   confusion for beginners.
>
> So I'm not dead set against it, but I'm not really sure it'd be an
> improvement either.

Just to show you that weird things are happening either way:

    (defun projectile-unixy-system-p ()
      "Check to see if unixy text utilities are installed."
      (--all? (executable-find it) '("grep" "cut" "uniq")))

Here's the implementation of `--all?'. It did not make sense to me
until I've spent an hour figuring it out.

    (defmacro --all? (form list)
      "Anaphoric form of `-all?'."
      (declare (debug (form form)))
      (let ((a (make-symbol "all")))
        `(let ((,a t))
           (--each-while ,list ,a (setq ,a ,form))
           (---truthy? ,a))))

Here's the 100% equivalent implementation of `--all?':

    (defmacro --all? (form list)
      "Anaphoric form of `-all?'."
      (declare (debug (form form)))
      `(cl-every (lambda (it) ,form) ,list))

Here's how `projectile-unixy-system-p' could be implemented with the
new reader macro:

    (defun projectile-unixy-system-p ()
      "Check to see if unixy text utilities are installed."
      (cl-every #(executable-find %) '("grep" "cut" "uniq")))

2 chars longer than the impl. with `dash', 1 char shorter if `every'
was used in place of `cl-every'.  I just want 3rd party packages to
use the core Emacs more, so that they are easier to read.

> Of course, your proposal has 2 parts:
> - the #(...) reader syntax.
> - the new macro.
> They work together but can also be used separately.  E.g. we could have
> just the macro and write things like (mapcar (code (+ % 1)) list).
> And we could have just the #(...) syntax and give it any meaning we like.

You're right on this one. Let me just recall the point of familiarity:
there's a lot of Clojure programmers coming to Emacs, thanks to CIDER.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On 01/22/2015 09:22 AM, Oleh wrote:
>>>     #(foo bar) should translate to (short-lambda (foo bar))
>>
>> Hmm...
>>
>> Not completely sure where I stand on this.
> 
> Thanks for the consideration in any case. And I'm glad that I asked
> this, even if it doesn't lead to a change.
> 
>> A few notes:
>> - I like the generality of CL reader macros.
>> - But extending elisp-mode to understand what's going on (and "do the
>>   right thing") with each new reader macro is not easy.

That's a problem with any lisp that provides a reader-macro facility.
The onus is on the authors of macro packages to create macros that work
well with the existing emacs-lisp-mode parser.

>>   So I'm currently against addition of CL style reader macros.

Stefan, is emacs-lisp-mode support your only objection?

> I'm afraid that making CL style macros available to the public would
> lead to more 3rd party extensions defining control structures used by
> other 3rd party extensions. My opinion is that only the core should be
> allowed to do that. Or at least the 3rd party control flow structures
> should not propagate.

We already have plenty of libraries defining "control flow" structures;
look at all the anaphoric-if libraries out there. ITYM "lexical
structure", not "control structure".

> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stefan Monnier]

> That's a problem with any lisp that provides a reader-macro facility.
> The onus is on the authors of macro packages to create macros that work
> well with the existing emacs-lisp-mode parser.

That's a good point.

>>> So I'm currently against addition of CL style reader macros.
> Stefan, is emacs-lisp-mode support your only objection?

Yes and no.  No in the sense that I expect that introducing such reader
macros will have consequences that go further than just "emacs-lisp-mode
support".

Maybe we could introduce a more limited form of reader macros.
E.g. allow #<letter><sexp> and make the reader return

   (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)

So it would allow introducing a special regexp syntax #r"regexp" (which
would for example swap the meaning of ( and \( and things like that),
but it wouldn't allow defining "raw string" (backslashes would quote the
" just as usual).

> We already have plenty of libraries defining "control flow" structures;
> look at all the anaphoric-if libraries out there.

Agreed, and I think it's a good thing.


        Stefan

Reader macros (Was: Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

On 01/22/2015 03:36 PM, Stefan Monnier wrote:
> Maybe we could introduce a more limited form of reader macros.
> E.g. allow #<letter><sexp> and make the reader return
> 
>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)


That's an excellent idea.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Reader macros

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

> On 01/22/2015 03:36 PM, Stefan Monnier wrote:
>> Maybe we could introduce a more limited form of reader macros.
>> E.g. allow #<letter><sexp> and make the reader return
>> 
>>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>
>
> That's an excellent idea.

Doesn't work well where <letter> is an unmatched delimiter like ( or [.

Also would not work with #r"xxx" raw strings.  I think it makes more
sense (like Guile does it) to make this kind of funcall not with <sexp>
but rather with <port>.  If indeed a sexp is wanted, calling `read' is
trivial.

-- 
David Kastrup

Re: Reader macros

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On 01/23/2015 01:33 AM, David Kastrup wrote:
> Daniel Colascione <dancol@dancol.org> writes:
> 
>> On 01/22/2015 03:36 PM, Stefan Monnier wrote:
>>> Maybe we could introduce a more limited form of reader macros.
>>> E.g. allow #<letter><sexp> and make the reader return
>>>
>>>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>>
>>
>> That's an excellent idea.
> 
> Doesn't work well where <letter> is an unmatched delimiter like ( or [.

So? The point isn't to support every conceivable syntax, but to cover
the most common use cases without fundamentally changing the lexical
structure of the source. Requiring #f() instead of #() is no great crime.

> Also would not work with #r"xxx" raw strings.

Arguably a feature, not a bug.

> I think it makes more
> sense (like Guile does it) to make this kind of funcall not with <sexp>
> but rather with <port>.  If indeed a sexp is wanted, calling `read' is
> trivial.

Sure, it's possible to do it that way, but then reader macros can break
the lexical structure of the program. The only legitimate use case
Stefan's idea doesn't cover is raw strings (and maybe here docs), for
which I would be willing to add a special case to the reader if we
decided we wanted them.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Reader macros

[David Kastrup]

Daniel Colascione <dancol@dancol.org> writes:

> On 01/23/2015 01:33 AM, David Kastrup wrote:
>> Daniel Colascione <dancol@dancol.org> writes:
>> 
>>> On 01/22/2015 03:36 PM, Stefan Monnier wrote:
>>>> Maybe we could introduce a more limited form of reader macros.
>>>> E.g. allow #<letter><sexp> and make the reader return
>>>>
>>>>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>>>
>>>
>>> That's an excellent idea.
>> 
>> Doesn't work well where <letter> is an unmatched delimiter like ( or [.
>
> So? The point isn't to support every conceivable syntax, but to cover
> the most common use cases without fundamentally changing the lexical
> structure of the source. Requiring #f() instead of #() is no great crime.
>
>> Also would not work with #r"xxx" raw strings.
>
> Arguably a feature, not a bug.
>
>> I think it makes more
>> sense (like Guile does it) to make this kind of funcall not with <sexp>
>> but rather with <port>.  If indeed a sexp is wanted, calling `read' is
>> trivial.
>
> Sure, it's possible to do it that way, but then reader macros can break
> the lexical structure of the program.

Shrug.  That's LilyPond's way of embedding LilyPond code in Scheme.

Here is one arbitrary example: One escapes from LilyPond to Scheme
writing #<sexp> or $<sexp> (with slightly different semantics) and from
Scheme to LilyPond writing #{ code... #}, with arbitrary nesting and
full lexical closure:

incipit =
#(define-music-function (parser location incipit-music) (ly:music?)
  #{
    \once \override Staff.InstrumentName.stencil =
      #(lambda (grob)
        (let* ((instrument-name (ly:grob-property grob 'long-text))
               (align-x (ly:grob-property grob 'self-alignment-X 0))
               (align-y (ly:grob-property grob 'self-alignment-Y 0)))
        (set! (ly:grob-property grob 'long-text)
          #{ \markup {
            \score
            {
              \new MensuralStaff \with {
                \override InstrumentName.self-alignment-X = #align-x
                \override InstrumentName.self-alignment-Y = #align-y
                instrumentName = #instrument-name
              }
              {
                $incipit-music
              }
              \layout {
                $(ly:grob-layout grob)
                indent-incipit-default = 15\mm
                line-width = #(primitive-eval
                  '(or (false-if-exception indent)
                    indent-incipit-default))
                indent = #(primitive-eval
                           '(or (false-if-exception (- line-width incipit-width))
                            (* 0.5 line-width)))
                ragged-right = ##f
                ragged-last = ##f
                system-count = 1
                \context {
                  \Score
                  \remove "Default_bar_line_engraver"
                }
              }
            }
            }
          #})
          (set! (ly:grob-property grob 'self-alignment-Y) #f)
          (set! (ly:grob-property grob 'self-alignment-X) RIGHT)
          (system-start-text::print grob)))
  #}
)

As you can see, it is one merry back-and-forth.  The implementation of
the LilyPond-within-Scheme embedding indeed uses a GUILE reader macro by
registering #{ and, upon being called, reading the string delimited by
#} from the port for later interpretation and registering each #<sexp>
or $<sexp> combination for potential lexical closure.

Now GUILE is touted more as a language-building tool than Elisp, of
course.  However, being able to adapt the Lisp reader to the task of
reading Scheme and even LilyPond/Scheme would make several parsing tasks
for LilyPond-mode easier, not just #{ ... #}.  For example, there is
#:xxx for keywords, and #(a b c d) for vectors and #\x for characters.
Being able to nudge the Elisp reader into dealing with this kind of sexp
would make for more robust detection of LilyPond vs Scheme code.

> The only legitimate use case Stefan's idea doesn't cover is

So reading Scheme or Scheme/LilyPond code is illegitimate?  Who gets to
decide this?

> raw strings (and maybe here docs), for which I would be willing to add
> a special case to the reader if we decided we wanted them.

-- 
David Kastrup

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That's a problem with any lisp that provides a reader-macro facility.
>> The onus is on the authors of macro packages to create macros that work
>> well with the existing emacs-lisp-mode parser.
>
> That's a good point.
>
>>>> So I'm currently against addition of CL style reader macros.
>> Stefan, is emacs-lisp-mode support your only objection?
>
> Yes and no.  No in the sense that I expect that introducing such reader
> macros will have consequences that go further than just "emacs-lisp-mode
> support".
>
> Maybe we could introduce a more limited form of reader macros.
> E.g. allow #<letter><sexp> and make the reader return
>
>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)

Would it not be possible to have the reader return a macro which could
do the cdr and assq at compile time and obviate the need for funcall?
This would be faster. It means that changes to reader-macro-alist
wouldn't be reflected in code till it was re-evaled.

My main concern with this as a proposal is that <letter> is a fairly
small namespace. There is a lot of possibility for pretty disasterous
clashes if this gets used in the wild.

Phil

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

>> Maybe we could introduce a more limited form of reader macros.
>> E.g. allow #<letter><sexp> and make the reader return
>>
>>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>
> Would it not be possible to have the reader return a macro which could
> do the cdr and assq at compile time and obviate the need for funcall?
> This would be faster. It means that changes to reader-macro-alist
> wouldn't be reflected in code till it was re-evaled.
>
> My main concern with this as a proposal is that <letter> is a fairly
> small namespace. There is a lot of possibility for pretty disasterous
> clashes if this gets used in the wild.

How about this:

    #a(...) is (reader-macro-a ...)
    #b(...) is (reader-macro-b ...)

    ...

    #z(...) is (reader-macro-z ...)

This would be easy to implement, since this is just an extension of
the `backquote' and `short-lambda' method to 26 reader macros.

The core could take over some of them, and leave the rest open to the
public.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Phillip Lord]

Oleh <ohwoeowho@gmail.com> writes:

>>> Maybe we could introduce a more limited form of reader macros.
>>> E.g. allow #<letter><sexp> and make the reader return
>>>
>>>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>>
>> Would it not be possible to have the reader return a macro which could
>> do the cdr and assq at compile time and obviate the need for funcall?
>> This would be faster. It means that changes to reader-macro-alist
>> wouldn't be reflected in code till it was re-evaled.
>>
>> My main concern with this as a proposal is that <letter> is a fairly
>> small namespace. There is a lot of possibility for pretty disasterous
>> clashes if this gets used in the wild.
>
> How about this:
>
>     #a(...) is (reader-macro-a ...)
>     #b(...) is (reader-macro-b ...)
>
>     ...
>
>     #z(...) is (reader-macro-z ...)
>
> This would be easy to implement, since this is just an extension of
> the `backquote' and `short-lambda' method to 26 reader macros.


That would work, but I don't think it's necessary -- if there is a
compile time lookup, it's just as efficient. More over, it's not
necessarily 26 macros -- if emacs is multi-byte then there are a lot of
potential macros.

It would even be possible to do

#symbol <form>

where symbol is any length, which would help to avoid the namespace
problem -- this is pretty much the expressivity of tagged literals in
Clojure. Although, my experience in Clojure is that few people use them,
because they must be namespaced so take too long to type (and for other
reasons I think).

> The core could take over some of them, and leave the rest open to the
> public.

I'd agree that single (and probably two) letter symbols would have to be
restricted to the core by convention.

Phil

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On 01/23/2015 03:53 AM, Phillip Lord wrote:
>> This would be easy to implement, since this is just an extension of
>> the `backquote' and `short-lambda' method to 26 reader macros.
> 
> 
> That would work, but I don't think it's necessary -- if there is a
> compile time lookup, it's just as efficient. 

I've found that people who engage in handwringing about efficiency of a
system they don't understand produce terrible code. Try implementing it
before worrying about micro-optimizations.

You're over-thinking the semantics too. The whole point of Stefan's
proposal is that it's very simple, but still delivers most of the
benefits of unrestricted reader macro support. Qualifiers like "by
convention, identifiers would have to restricted..." is a step down the
road to adding overgrown Clojure ceremony for everything, something I
definitely do not want in Emacs Lisp.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]

On 01/23/2015 02:34 AM, Phillip Lord wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> That's a problem with any lisp that provides a reader-macro facility.
>>> The onus is on the authors of macro packages to create macros that work
>>> well with the existing emacs-lisp-mode parser.
>>
>> That's a good point.
>>
>>>>> So I'm currently against addition of CL style reader macros.
>>> Stefan, is emacs-lisp-mode support your only objection?
>>
>> Yes and no.  No in the sense that I expect that introducing such reader
>> macros will have consequences that go further than just "emacs-lisp-mode
>> support".
>>
>> Maybe we could introduce a more limited form of reader macros.
>> E.g. allow #<letter><sexp> and make the reader return
>>
>>    (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
> 
> Would it not be possible to have the reader return a macro which could
> do the cdr and assq at compile time and obviate the need for funcall?
> This would be faster. It means that changes to reader-macro-alist
> wouldn't be reflected in code till it was re-evaled.

This paragraph is hard to parse, but ITYM that instead of literally
calling funcall as Stefan described, the reader would mechanically
transform _any_ construct of the form #LS, L being a letter and S being
a sexp, into something like (expand-reader-macro 'L 'S).

Maybe that could work, if the scoping rules (see below) were preserved.
In any case, it's just an implementation detail.

> My main concern with this as a proposal is that <letter> is a fairly
> small namespace. There is a lot of possibility for pretty disasterous
> clashes if this gets used in the wild.

Of course. That's why we'd make each file register an association
between letters and the macros to which they'd expand. Think of how XML
namespaces map short local names to long global names. We'd make this
mapping buffer-local, like lexical-binding.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Phillip Lord]

Daniel Colascione <dancol@dancol.org> writes:

>> My main concern with this as a proposal is that <letter> is a fairly
>> small namespace. There is a lot of possibility for pretty disasterous
>> clashes if this gets used in the wild.
>
> Of course. That's why we'd make each file register an association
> between letters and the macros to which they'd expand. Think of how XML
> namespaces map short local names to long global names. We'd make this
> mapping buffer-local, like lexical-binding.

That could work so long as there is a standard convention for adding to
this. The normal

(require 'my-special-reader-macros)

wouldn't be enough.

Still, think I have said enough. Something of this sort seems to be a
good idea to me.

Phil

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stefan Monnier]

>> Maybe we could introduce a more limited form of reader macros.
>> E.g. allow #<letter><sexp> and make the reader return
>> (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
> Would it not be possible to have the reader return a macro which could
> do the cdr and assq at compile time and obviate the need for funcall?

I like that.  Because it solves the main problem I had with my proposal,
which was to make `read' into something whose safety depends on
"somewhat arbitrary Elisp code".

> My main concern with this as a proposal is that <letter> is a fairly
> small namespace.

Well, "letter" could easily be extended to "identifer".  But of course,
there'd be a lot of pressure on the single-letter identifiers anyway.


        Stefan

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stefan Monnier]

>>> Maybe we could introduce a more limited form of reader macros.
>>> E.g. allow #<letter><sexp> and make the reader return
>>> (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>> Would it not be possible to have the reader return a macro which could
>> do the cdr and assq at compile time and obviate the need for funcall?
> I like that.  Because it solves the main problem I had with my proposal,
> which was to make `read' into something whose safety depends on
> "somewhat arbitrary Elisp code".

Actually, no I think this is not good.  The problem is that it means
such reader macros are just plain normal macros, i.e. they're only
expanded when they're in an "evaluated expression" position.
So you wouldn't be able to use them within a quoted list, for example.


        Stefan

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> Maybe we could introduce a more limited form of reader macros.
>>>> E.g. allow #<letter><sexp> and make the reader return
>>>> (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>>> Would it not be possible to have the reader return a macro which could
>>> do the cdr and assq at compile time and obviate the need for funcall?
>> I like that.  Because it solves the main problem I had with my proposal,
>> which was to make `read' into something whose safety depends on
>> "somewhat arbitrary Elisp code".
>
> Actually, no I think this is not good.  The problem is that it means
> such reader macros are just plain normal macros, i.e. they're only
> expanded when they're in an "evaluated expression" position.
> So you wouldn't be able to use them within a quoted list, for example.


Ah, I'd misunderstood your original proposal to be honest. When you say
"make the reader return 
(funcall (cdr (assq <letter> reader-macro-alist)) sexp)", you meant
return the return value of the form, not return the form. Daniel was
right, I hadn't understood the system.


Phil

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Oleh]

On Thu, Jan 22, 2015 at 9:34 PM, Daniel Colascione <dancol@dancol.org> wrote:

> We already have plenty of libraries defining "control flow" structures;
> look at all the anaphoric-if libraries out there. ITYM "lexical
> structure", not "control structure".

Could you please add a link to the mentioned anaphoric-if libraries?
I'm curious how many there are.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Stefan Monnier]

> Or at least the 3rd party control flow structures should
> not propagate.

I actually disagree here.  I think it's perfectly fine to define new
control structures, either in 3rd party libraries or locally for use in
your own file.  It's one of the main strengths of Lisp.

> Am I right in the assumption that only current #(...) syntax is that
> of #("foo" ...)? Nothing other than propertized strings uses it?

I didn't check the C code, but I believe that's right, yes.

> Note that #(foo %) is open to optimizations: it doesn't have to be
> exactly (lambda (%) (foo %)),

(lambda (%) (foo %)) is also open to optimizations, and actually to
probably exactly the same optimizations.

Not that we bother to perform any anyway (because there really aren't
many such optimizations that can be done reliably without a fair bit of
analysis).

> Just to show you that weird things are happening either way:
>     (defun projectile-unixy-system-p ()
>       "Check to see if unixy text utilities are installed."
>       (--all? (executable-find it) '("grep" "cut" "uniq")))

It's OK.  Languages evolve, and I'm fine with it.  I'm not fond of
anaphoric macros (I tend to think of them as "anti-hygienic macros"
instead), but that's only a matter of taste.


        Stefan

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Artur Malabarba]

>>     #(foo bar) should translate to (short-lambda (foo bar))
>
> Hmm...
>
> Not completely sure where I stand on this.
> A few notes:
> [...]
> - But the current Elisp implementation is not good at handling function
>   calls efficiently, so offering a very short syntax like #(foo bar) is
>   kind of lying to the programmer.

OTOH, 98% of elisp code doesn't care *that* much about efficiency. And
the programmers who need to write that 2% will look into it and learn
about the function call ineficiency.

As an example of the former, see how popular the (repeatedly
mentioned) dash library is. It's full of ineficient code (most
functions and macros are implemented in the simplest way, not the
fastest). Yet, it's very widely used among the repositories.

Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal

[Barry OReilly]

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

> (car #(fubAr quux)) => 'lambda
>
> would be *very* surprising to most users.  That kind of computation is
> what functions are for.

Taking the car of a function is not valid anyway.

Byte compile:

  (defvar myfunc (lambda ()))

Evaluate:

  (car myfunc)

Error:

  Debugger entered--Lisp error: (wrong-type-argument listp #[nil "\300\207"
[nil] 1])
    car(#[nil "\300\207" [nil] 1])
    eval((car (byte-compile (function (lambda nil)))) nil)
    eval-last-sexp-1(nil)
    eval-last-sexp(nil)
    call-interactively(eval-last-sexp nil nil)
    command-execute(eval-last-sexp)

Or in the *scratch* buffer:

  (setq lexical-binding t)
  (car (lambda ())) ; => 'closure

[-- Attachment #2: Type: text/html, Size: 867 bytes --]