Revisiting The ZIP Dialect

Vincent Ecuyer's ZIP Dialect is an example of tool in a domain that pretty much everyone knows and uses: zipping and unzipping files.

I'd thought its source code might be a good place to study the power of BINARY! parsing...until I realized how lacking binary parsing actually was in practice. With UPARSE, I hope to attack those problems. If so, then ZIP may yet become a showcase of how something like the zip file specification can become easily absorbed as usermode code.

But another opportunity may come from making the ZIP dialect a tool people would actually want to use for its powers.

It's already a little bit dialected. When you pass it a block, you don't just specify filenames. You can also give it literal blobs of BINARY! data, or URL!s to fetch. This means you don't have to do calls to curl to get a temporary file, rename that file, and then pass the filename to a zip tool... the tool itself has smarts.

Here's what the options were in the original script:

you can zip a single file:
    zip %my-file

a block of files:
    zip [%file-1.txt %file-2.exe]

a block of data (binary!/string!) and files:
    zip [%my-file "my data"]

a entire directory:
    zip/deep %my-directory/

from an url:

any combination of these:
    zip/deep  [
        %readme.txt "An example"

When you think of this being used alongside my demo of steps in GitHub Actions we could pack it up. Here's a sketch of what that might look like:

 - uses: hostilefork/zip-github-action@v1
   deep: true
   run: |
       %readme.txt "An example"

The ideal would be that there be a very easy way to make such a packaging for any given ACTION!. You want to be able to get the non-dialect arguments and refinements split out from the body (the way the output filename and /DEEP is split out here).

This Seems Like A Good Example to Try And Hone

It doesn't really get any simpler than this. So why don't we ask:

Can we make the ZIP dialect something so compelling that anyone who wanted to make a ZIP file on GitHub Actions would be a fool not to use it, if it had a zero-effort usage pattern like the above?

The dialect could take advantage of new parts in the box. e.g. SET-BLOCK! if you want to use a different filename than what something has already:

; Make a file in the zip called bar.txt, with contents of foo.txt
zip [[%bar.txt]: %foo.txt]

; Make a file in the zip called foo.txt, with contents of foo.txt
zip [%foo.txt]

Talking to @BlackATTR about it, I wondered if it's the kind of dialect where plain WORD!, PATH!, and TUPLE! should be interpreted as filenames, just to reduce the level of noise. So readme.txt would be a legal alternative to %readme.txt and you would use GROUP!s to run code. This introduces a lot of questions, but I've brought up the question elsewhere, e.g. with FORM.

Playing along better with bash would be nice. Maybe allow $ (some bash expression)? I've got a post about a SHELL dialect I've been thinking about.

Anyway, if we can't do this, we probably can't do anything more complicated. So it's time to start putting our code where our mouth is and seeing if this can actually make something anyone wanted to use.


I think this is a good way to look at it. In other words, view it from the angle of somebody who doesn't care in the slightest about ren-c or rebol, they just want a useful easy-to-pick-up tool that does one or two things well.

Most people just want the banana, they don't want the banana which is attached to the gorilla and the rest of the whole jungle that goes along with it (apologies to Joe Armstrong).

With that in mind, I think this kind dialect should look more like a syntax the developer might already be familiar with, as opposed to something which delves into syntax/idioms of rebol.

And yes, this is a pretty good exercise to see if ren-c can do a good job in this space. And bonus points are in order if the dialect is designed in such a way so that other dialects can easily invoke it/output to it. :wink: