Re: [elpa] externals/consult 4aa49ee324 3/5: consult--async-pipeline: Convert to function

Re: [elpa] externals/consult 4aa49ee324 3/5: consult--async-pipeline: Convert to function

[Stefan Monnier]

> +  (lambda (sink)
> +    (seq-reduce (lambda (s f) (funcall f s)) (reverse async) sink)))

Hmm... Haskell/OCaml have `foldr` and `foldl`, maybe we should also have
`reduceR` and `reduceL`.


        Stefan

Re: [elpa] externals/consult 4aa49ee324 3/5: consult--async-pipeline: Convert to function

[Daniel Mendler via Emacs development discussions.]

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

>> +  (lambda (sink)
>> +    (seq-reduce (lambda (s f) (funcall f s)) (reverse async) sink)))
>
> Hmm... Haskell/OCaml have `foldr` and `foldl`, maybe we should also have
> `reduceR` and `reduceL`.

Yes, please. seq-reduce-right/left would be nice to have. See also
cl-reduce which has :from-end.

There is also a lack in some combinators (flip, curry, uncurry, ...)
which are occasionally useful. Also papply and rpapply, since
apply-partially lacks conciseness and sometimes one wants apply the
arguments to the right. Same with cl-constantly.

(papply #'f x)
(apply-partially #'f x)
(lambda (y) (f x y))
(lambda (y z) (f x y z))

(lambda (_) x)
(constantly x)
(lambda (_ _) x)
(cl-constantly x)

Daniel

Short functions (was: [elpa] externals/consult 4aa49ee324 3/5: consult--async-pipeline: Convert to function)

[Stefan Monnier]

>> Hmm... Haskell/OCaml have `foldr` and `foldl`, maybe we should also have
>> `reduceR` and `reduceL`.
> Yes, please. seq-reduce-right/left would be nice to have. See also
> cl-reduce which has :from-end.

FWIW, I can never remember which is "right" and which is "left", so
I much prefer the "from end" kind of terminology.
Combined with the existence of `seq-reduce`, that would suggest the use
of `seq-reduce-from-end`.

[ This said, when the sequence is a list as is presumably the case here,
  as long as it's coded in ELisp I suspect the most efficient solution
  is to `reverse` and then do `seq-reduce`, just like you did.  To be
  more efficient, we'd want to avoid both heap allocation and recursion,
  but sadly from ELisp the only way to allocate non-heap memory is via
  recursion.  At the bytecode level there's some limited support for
  stack allocation but it's limited by the fact that the max size has to
  be declared in the bytecode object and that this max size is
  pre-allocated (so it can't be made ridiculously large).  ]

> There is also a lack in some combinators (flip, curry, uncurry, ...)
> which are occasionally useful. Also papply and rpapply, since
> apply-partially lacks conciseness and sometimes one wants apply the
> arguments to the right. Same with cl-constantly.
>
> (papply #'f x)
> (apply-partially #'f x)
> (lambda (y) (f x y))
> (lambda (y z) (f x y z))
>
> (lambda (_) x)
> (constantly x)
> (lambda (_ _) x)
> (cl-constantly x)

I think you're arguing for something like `llama`s ## or to expand #'
to allow things like:

    #'(f x _)
    #'(f x _ _)
    #'(f x . _)
    #'(_ → x)
    #'(_ _ → x)

Then again, there's

    (λ (y) (f x y))
    (λ (y z) (f x y z))
    (λ (_) x)
    (λ (_ _) x)

I'm interested to add new meanings to `function` (aka #') but mostly for
things like:

    #'(setf foo)
    #'(peg foo)

to refer to the setters or the peg-matchers of a given name.  It could
also be used for

    #'(cl-lambda ...)

instead of the hideous

    (cl-function (lambda ...))

tho this one completely depends on the reason (that completely escapes
me) for the use of a `cl-function` macro instead of a `cl-lambda` macro.


        Stefan

Re: Short functions (was: [elpa] externals/consult 4aa49ee324 3/5: consult--async-pipeline: Convert to function)

[Daniel Colascione]

On January 6, 2025 11:52:12 AM EST, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>  more efficient, we'd want to avoid both heap allocation and recursion,
>  but sadly from ELisp the only way to allocate non-heap memory is via
>  recursion. 

Hopefully, generational GC will make heap allocation much less burdensome and the need for stack allocation (and escape analysis) less pressing.

Re: Short functions

[Daniel Mendler via Emacs development discussions.]

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

>> There is also a lack in some combinators (flip, curry, uncurry, ...)
>> which are occasionally useful. Also papply and rpapply, since
>> apply-partially lacks conciseness and sometimes one wants apply the
>> arguments to the right. Same with cl-constantly.
>>
>> (papply #'f x)
>> (apply-partially #'f x)
>> (lambda (y) (f x y))
>> (lambda (y z) (f x y z))
>>
>> (lambda (_) x)
>> (constantly x)
>> (lambda (_ _) x)
>> (cl-constantly x)
>
> I think you're arguing for something like `llama`s ## or to expand #'
> to allow things like:

Actually I like the explicitly named combinators (constantly, identity,
papply, etc). Nevertheless some Llama-style syntax would be nice to have
in Elisp. It doesn't have to reuse the #' syntax.

> I'm interested to add new meanings to `function` (aka #') but mostly for
> things like:
>
>     #'(setf foo)
>     #'(peg foo)
>
> to refer to the setters or the peg-matchers of a given name.  It could
> also be used for

Good idea.

Daniel

Re: Short functions

[Daniel Colascione]

On January 6, 2025 12:02:43 PM EST, "Daniel Mendler via Emacs development discussions." <emacs-devel@gnu.org> wrote:
>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> There is also a lack in some combinators (flip, curry, uncurry, ...)
>>> which are occasionally useful. Also papply and rpapply, since
>>> apply-partially lacks conciseness and sometimes one wants apply the
>>> arguments to the right. Same with cl-constantly.
>>>
>>> (papply #'f x)
>>> (apply-partially #'f x)
>>> (lambda (y) (f x y))
>>> (lambda (y z) (f x y z))
>>>
>>> (lambda (_) x)
>>> (constantly x)
>>> (lambda (_ _) x)
>>> (cl-constantly x)
>>
>> I think you're arguing for something like `llama`s ## or to expand #'
>> to allow things like:
>
>Actually I like the explicitly named combinators (constantly, identity,
>papply, etc). Nevertheless some Llama-style syntax would be nice to have
>in Elisp. It doesn't have to reuse the #' syntax.

Sure, but it'd be nice to maintain the syntactic structure of current code instead of, say, introducing new punctuation. I used to be upset that we don't have reader macros. Now I'm not.

>
>> I'm interested to add new meanings to `function` (aka #') but mostly for
>> things like
>>
>>     #'(setf foo)
>>     #'(peg foo)
>>
>> to refer to the setters or the peg-matchers of a given name.  It could
>> also be used for
>
>Good idea.
>
>Daniel
>

Re: Short functions

[Stefan Monnier]

>> more efficient, we'd want to avoid both heap allocation and recursion,
>> but sadly from ELisp the only way to allocate non-heap memory is via
>> recursion.
> Hopefully, generational GC will make heap allocation much less burdensome
> and the need for stack allocation (and escape analysis) less pressing.

+1 (and concurrent GC would also do the trick since we can generally
assume that there are free cycles available on another core)

Still, I keep hoping for a clever way to allow explicit avoidance of
heap allocation for those cases where the coder can be bothered to
make extra efforts for that.


        Stefan

Re: Short functions

[Daniel Colascione]

On January 6, 2025 12:25:27 PM EST, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> more efficient, we'd want to avoid both heap allocation and recursion,
>>> but sadly from ELisp the only way to allocate non-heap memory is via
>>> recursion.
>> Hopefully, generational GC will make heap allocation much less burdensome
>> and the need for stack allocation (and escape analysis) less pressing.
>
>+1 (and concurrent GC would also do the trick since we can generally
>assume that there are free cycles available on another core)

Generational will help with energy too though: unlike a concurrent collector, adding generational collection reduces the total work the collector does and doesn't just shift the work to another core.