make txexpr a match-expander #8

Closes #7.

> (match '(p ((key "value")) "leaf")
    [(txexpr 'p `((key ,val)) (list "leaf")) val])
"value"

Closes #7. ```racket > (match '(p ((key "value")) "leaf") [(txexpr 'p `((key ,val)) (list "leaf")) val]) "value" ```

The define-module-boundary-contract form is only available on versions 6.0.1 and later.

The `define-module-boundary-contract` form is only available on versions 6.0.1 and later.

@mbutterick do we really need to support Racket 6.0? It's almost 5 years old now...

Yes, otherwise I have to rev pollen too.

Yes, otherwise I have to rev `pollen` too.

I think if you branch and version-exception this one you don’t have to do that for pollen - as long as you don’t use the txexpr match form in pollen

Why not just copy the source for define-module-boundary-contract into this repo.

Why not just copy the source for `define-module-boundary-contract` into this repo.

If that’s on the table, wouldn’t it be better to make a package that only provides define-module-boundary-contract? Normally it would just reprovide the form from racket/contract/base, but it would have a version exception for version 6.0. The package could be called ”module-boundary-contract-compat”.

Other packages would depend on this package so that they don’t need a version exception themselves.

If that’s on the table, wouldn’t it be better to make a package that only provides `define-module-boundary-contract`? Normally it would just reprovide the form from `racket/contract/base`, but it would have a version exception for version 6.0. The package could be called `”module-boundary-contract-compat”`. Other packages would depend on this package so that they *don’t need* a version exception themselves.

“Better” in an abstract sense, though I still prefer the dumb solution (copy & paste) because it’s temporary. At some point next year I will drop support for Rackets < 6.3, and that day, I can delete the code.

There have been a lot of things I've noticed I use a lot which were added between 6.0 and 6.0.1. Particularly in Typed Racket things improved a lot with that version change, and apparently this too.

P.S. I was curious and it looks like the particular commit that added define-module-boundary-contract immediately used it to help Typed Racket so that's interesting I guess
c321f6dd0c (diff-f335d0535dec069ee865477e5c19228bR144)

There have been a lot of things I've noticed I use a lot which were added between 6.0 and 6.0.1. Particularly in Typed Racket things improved a lot with that version change, and apparently this too. P.S. I was curious and it looks like the particular commit that added `define-module-boundary-contract` immediately used it to help Typed Racket so that's interesting I guess https://github.com/racket/racket/commit/c321f6dd0c4e2444d44b6c79a3ac49acfb9041bf#diff-f335d0535dec069ee865477e5c19228bR144

Why not just give the match expander a separate name, like tx? Doesn’t that avoid all the trouble?

Why not just give the match expander a separate name, like `tx`? Doesn’t that avoid all the trouble?

Why not just give the match expander a separate name, like tx? Doesn’t that avoid all the trouble?

That would avoid the problem, but it also means that we will need to support tx from now on for backward compat, even after Racket 6.0 is not supported anymore (that is, even when we can support the txexpr form easily). Are you OK with that?

Also, most match-expander seems to be a constructor name (list, vector, box, etc.). I don't know what's the cost for breaking the convention.

> Why not just give the match expander a separate name, like tx? Doesn’t that avoid all the trouble? That would avoid the problem, but it also means that we will need to support `tx` from now on for backward compat, even after Racket 6.0 is not supported anymore (that is, even when we can support the `txexpr` form easily). Are you OK with that? Also, most match-expander seems to be a constructor name (`list`, `vector`, `box`, etc.). I don't know what's the cost for breaking the convention.

I'm having a lot of trouble implementing the "copy & paste" solution in 6.0, because it relies on the idea of a val-first projection contract, which was only introduced in 6.0.1.

I'm having a lot of trouble implementing the "copy & paste" solution in 6.0, because it relies on the idea of a [_val-first projection_](https://docs.racket-lang.org/reference/contract-utilities.html#%28def._%28%28lib._racket%2Fcontract%2Fprivate%2Fguts..rkt%29._contract-val-first-projection%29%29) contract, which was only introduced in 6.0.1.

Also, how is this match expander different from just (list (? txexpr-tag?) (? txexpr-attrs?) (? txexpr-elements?))

Also, how is this match expander different from just `(list (? txexpr-tag?) (? txexpr-attrs?) (? txexpr-elements?))`

In the same ways that (txexpr->values tx) is different from (apply values tx), I guess. And that's the whole reason this package is super useful in the first place.

Edit: You probably meant (list-rest (? txexpr-tag?) (? txexpr-attrs?) (? txexpr-elements)), which breaks the correspondence with apply values. But txexpr->values's handling of the two different forms of txexprs, with and without the attributes list, is still important for this.

In the same ways that `(txexpr->values tx)` is different from `(apply values tx)`, I guess. And that's the whole reason this package is super useful in the first place. Edit: You probably meant `(list-rest (? txexpr-tag?) (? txexpr-attrs?) (? txexpr-elements))`, which breaks the correspondence with `apply values`. But `txexpr->values`'s handling of the two different forms of txexprs, with and without the attributes list, is still important for this.

If I controlled this package I would probably:

Create a new branch called for-v-up-to-6.0 that starts the same as the current master branch.
Create a version exception on the Package Server pointing 6.0 queries to git://github.com/mbutterick/txexpr#for-v-up-to-6.0
Move master forward in ways that are compatible with 6.0.1 and above, but don't have to be compatible with 6.0, and leave for-v-up-to-6.0 the way it is.

If I controlled this package I would probably: 1. Create a new branch called `for-v-up-to-6.0` that starts the same as the current `master` branch. 2. Create a version exception on the Package Server pointing 6.0 queries to `git://github.com/mbutterick/txexpr#for-v-up-to-6.0` 3. Move `master` forward in ways that are compatible with 6.0.1 and above, but don't have to be compatible with 6.0, and leave `for-v-up-to-6.0` the way it is.

Thar she blows.

Apparently the version exception is not working. I’ve never used it before. Do you know how I resolve this error?

6.03s$ travis_retry raco pkg install --deps search-auto --link pollen
Resolving "txexpr" via http://download.racket-lang.org/releases/6.0/catalog/
Resolving "txexpr" via http://pkgs.racket-lang.org
Cloning remote directory https://github.com/mbutterick/txexpr.git#6.0-version-exception
raco pkg install: could not find MANIFEST for package source
  source: https://github.com/mbutterick/txexpr.git#6.0-version-exception

Apparently the version exception is not working. I’ve never used it before. Do you know how I resolve this error? ``` 6.03s$ travis_retry raco pkg install --deps search-auto --link pollen Resolving "txexpr" via http://download.racket-lang.org/releases/6.0/catalog/ Resolving "txexpr" via http://pkgs.racket-lang.org Cloning remote directory https://github.com/mbutterick/txexpr.git#6.0-version-exception raco pkg install: could not find MANIFEST for package source source: https://github.com/mbutterick/txexpr.git#6.0-version-exception ```

Oh, I think that's because Racket version 6.0 didn't understand that the .git extension meant it was a git repo. I think if you remove the .git and change https:// to git:// that will fix it. But you might have to (on the Package Catalog) say that it's "not" a git repo, that it's just a simple url git://github.com/mbutterick/txexpr#6.0-version-exception to do that.

P.S. according to the History annotations in the docs Racket only started recognizing the .git extension in version 6.1.1.1, so for versions before then we had to use git:// or github:// to specify that

Oh, I think that's because Racket version 6.0 didn't understand that the `.git` extension meant it was a git repo. I think if you remove the `.git` and change `https://` to `git://` that will fix it. But you might have to (on the Package Catalog) say that it's "not" a git repo, that it's just a simple url `git://github.com/mbutterick/txexpr#6.0-version-exception` to do that. P.S. according to the History annotations in the docs Racket only started recognizing the `.git` extension in version 6.1.1.1, so for versions before then we had to use `git://` or `github://` to specify that

Labels Milestones

make txexpr a match-expander #8

Step 1:

Step 2: