Multi-way zip

[CryptoPascal31]

Is your enhancement request related to a problem? Please describe.

Yes.. There is no multi-ways (more than 2) zip in Pact.

Describe the solution you'd like

I would be happy if zip could accept more than a two arguments:
Example:

(zip (lambda (a b c) (format "{} says {} to {}" [a b c]))
       ["Pascal" "Jose"]
       ["Hello", "Good morning"]
       ["Amir", "Stuart"])

["Pascal says Hello to Amir", "Jose says Good morning to Stuart"]

Describe alternatives you've considered

Simulating N-ways zip by using existing "2-ways zip" is doable but is cumbersome and ugly.. It requires building different levels of temporary objects or list , and deconstructing them in the target function.

---

As always, this is only a suggestion... that should be balanced with ease of implementation.

[jmcardon]

Thanks for filing this issue.

This definitely should be possible if we raise zip from a simple function to a special form.

Do you find you have code you need to zip n lists often? Or is this more of a QOL enhancement which would make a particular piece of code cleaner?

I do see where you're coming from though. I am just curious whether it's worth to generalize this to n lists, or is adding up to say zip5 enough.

[jmcardon]

Also p.s, moving forward in pact 5, we will no longer overload names with different arities. That's an artifact of the past.

In pact 5, something like (enumerate 0 10) and (enumerate 0 5 10) is actually two functions, enumerate and enumerate-step. This has to do primarily with how pact now semantically creates closures on all partial applications, not just on a few callsites.

So to explain the last line in the above comment: unless zip is raised to special form, If we add arities to zip, moving forward it would be something like zip3, zip4, zip5 most likely rather than making zip accept multiple arities, unless zip itself becomes special like with-capability and co.

[CryptoPascal31]

Do you find you have code you need to zip n lists often? Or is this more of a QOL enhancement which would make a particular piece of code cleaner?

Yes, I have one use case where zip-n would be needed. I want to transfer a set of amounts, through a set of modrefs to a set of receivers,

What I would like:

(module rewards-provider-xxx  GOV

  (defun get-pending:[decimal] ()
    ...
  )

  (defun --transfer-rewards:decimal (token:module{fungible-v2} receiver:string amount:decimal)
    (require-capability (PROVIDER-CAP rewards-provider-xxx))
      (if (= 0.0 amount) 0.0
          (do (install-capability (token::TRANSFER (account token) receiver amount))
              (with-capability (ACCOUNT-CAP token)
                (token::transfer (account token) receiver amount))
              amount)))
  )

  (defun pull-rewards:[decimal] (accounts:[string])
    (let ((to-transfer (get-pending)))
      (zip3 --transfer-rewards TOKENS accounts to-transfer)
      to-transfer)
  )

)

But, I found out a workaround (using a temporary object and two zips):

(module rewards-provider-xxx  GOV

 (defun get-pending:[decimal] ()
    ...
  )

  (defun --transfer-rewards:decimal (token:module{fungible-v2} dest:object)
    (require-capability (PROVIDER-CAP rewards-provider-xxx))
    (bind dest {'receiver:=receiver, 'amount:=amount}
      (if (= 0.0 amount) 0.0
          (do (install-capability (token::TRANSFER (account token) receiver amount))
              (with-capability (ACCOUNT-CAP token)
                (token::transfer (account token) receiver amount))
              amount)))
  )

  (defun pull-rewards:[decimal] (accounts:[string])
    (let ((to-transfer (get-pending)))
      (zip --transfer-rewards TOKENS
            (zip (lambda (r a) {'receiver:r, 'amount:a}) accounts to-transfer))
      to-transfer)
  )

)

The solution works but is not very clean, and becomes quickly a nightmare if you try to "simulate" 4, 5 arities.

So the answer is YES , it's a QOL enhancement, rather than an absolute requirement.

I do see where you're coming from though. I am just curious whether it's worth to generalize this to n lists, or is adding up to say zip5 enough.

To be honest, I have no preference: From my point of view:

• Implementing a n-arity zip is nice... It doesn't add more natives... and keep things clean.
• Having zip3, zip4 and zip5 has the advantage of creating less ambiguity

But definitively both solutions do the Job..; 😄