Re: Adding package "Loopy" to Non-GNU Devel?

[Okamsn]

Philip Kaludercic wrote:
> Okamsn <okamsn@protonmail.com> writes:
> 
>> Hello,
>>
>> I am the author of the package "loopy", which provides macros similar to
>> ~cl-loop~ and Common Lisp's =iterate=.  It is located here:
>>
>> https://github.com/okamsn/loopy
> 
> (Obligatory question here, as to why we don't also name the package
> iterate?)

To be clear, Loopy isn't a copy of Iterate. I originally set out to make 
a more featureful version of something like `cl-loop` and learned about 
Iterate the first time I asked that Loopy be added to MELPA 
(https://github.com/melpa/melpa/pull/7253). Note that Loopy is much 
improved since that discussion.

The macro for embedding the loop constructs in arbitrary code (see my 
previous e-mail for an example) I called `loopy-iter`, because I learned 
about the idea from Iterate (and because naming is hard), but it was 
written a few months after that MELPA discussion.

>> - Better destructuring than =cl-lib=, in that it can destructure arrays and
>>     supports destructuring in accumulations (like ~collect~) as well as in
>>     iteration.  I recently added a Pcase pattern for this outside of the
>> ~loopy~ macro.
>>
>>     #+begin_src emacs-lisp
>>       ;; => (8 10 12 14 16 18)
>>       (loopy (list list-elem '(([1 2 3] [4 5 6])
>>                                ([7 8 9] [10 11 12])))
>>              (sum ([sum1 sum2 sum3] [sum4 sum5 sum6])
>>                   list-elem)
>>              (finally-return sum1 sum2 sum3 sum4 sum5 sum6))
>>     #+end_src
> 
> Where is pcase being used here?

It is being use underneath, via `pcase-compile-patterns` on modern 
Emacs.  Previously, I was using custom functions to destructure the 
value. I am currently making an effort to simplify the package by 
removing the (then- or now-) re-invented wheels.

The Pcase pattern can be used directly in `pcase`:

#+begin_src emacs-lisp
   ;; => (1 2 3
   ;;     4 5 t
   ;;     (:k1 111 :k2 222)
   ;;     111 t
   ;;     222
   ;;     111
   ;;     333 nil
   ;;     4444 5555)
   (pcase (list 1 2 3 4 5 :k1 111 :k2 222)
     ((loopy ( a b c
               &optional
               d
               (e nil e-supplied)
               &rest
               r
               &key
               ((:k1 k1) nil k1-supplied)
               k2
               &map
               (:k1 map1)
               [:k3 map3 333 map3-supplied]
               &aux
               [x1 4444] (x2 5555)))
      (list a b c
            d
            e e-supplied
            r
            k1 k1-supplied
            k2
            map1
            map3 map3-supplied
            x1 x2)))
#+end_src

See the file `loopy-destructure.el` for its current implementation.

>> I am asking about Non-GNU Devel instead of just the normal Non-GNU archive
>> because I am still making breaking changes to the package as I reduce
>> duplication and improve on the ideas, but those changes are coming less
>> frequently now.
> 
> If you want to prevent a package from being released, you just need to
> make sure keep some negative version suffix like -rc in the version tag.


Would the workflow be to commit a change to increase the stable-version 
number and then to commit another change to change the version number to 
one with an "-rc" suffix to continue development?

> But in general, I wouldn't advise regarding NonGNU ELPA devel as a
> proper package archive for users, but more as a preview for developers
> to see how the ELPA build server is processing your package.  Or that is
> at least my take.

OK. Thank you for the explanation.

>> Is it possible to add this package and the extension package to the archive?
>>
>> I keep the extension package in the same GitHub repo as the main package for
>> testing purposes.  The Dash functionality was requested by a user, but
>> Dash is
>> not used by the rest of the package.  Because of that, I put the Dash
>> functionality in a small separate package.
> 
> You are talking about the loopy-dash.el file in the same branch, right?

Yes.

> If possible, it would be better if you could at least maintain it in a
> separate branch.

If I added the file "loopy-dash.el" to an ".elpaignore" file in the main 
branch and used GitHub Actions to push any changes from the main branch 
to another branch containing the file "loopy-dash.el", would that be 
acceptable?