make txexpr a match-expander #8

Merged
AlexKnauth merged 6 commits from match-expander into master 6 years ago
AlexKnauth commented 6 years ago (Migrated from github.com)

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" ```
AlexKnauth commented 6 years ago (Migrated from github.com)

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.
sorawee commented 6 years ago (Migrated from github.com)

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

@mbutterick do we really need to support Racket 6.0? It's almost 5 years old now...
mbutterick commented 6 years ago (Migrated from github.com)

Yes, otherwise I have to rev pollen too.

Yes, otherwise I have to rev `pollen` too.
AlexKnauth commented 6 years ago (Migrated from github.com)

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

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
mbutterick commented 6 years ago (Migrated from github.com)

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.
AlexKnauth commented 6 years ago (Migrated from github.com)

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.
mbutterick commented 6 years ago (Migrated from github.com)

ā€œ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.

ā€œ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.
AlexKnauth commented 6 years ago (Migrated from github.com)

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
mbutterick commented 6 years ago (Migrated from github.com)

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?
sorawee commented 6 years ago (Migrated from github.com)

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.
AlexKnauth commented 6 years ago (Migrated from github.com)

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.
mbutterick commented 6 years ago (Migrated from github.com)

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?))`
AlexKnauth commented 6 years ago (Migrated from github.com)

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.
AlexKnauth commented 6 years ago (Migrated from github.com)

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.
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.
mbutterick commented 6 years ago (Migrated from github.com)

Thar she blows.

Thar she blows.
mbutterick commented 6 years ago (Migrated from github.com)

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 ```
AlexKnauth commented 6 years ago (Migrated from github.com)

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
The pull request has been merged as f5ae897159.
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b match-expander master
git pull origin match-expander

Step 2:

Merge the changes and update on Gitea.
git checkout master
git merge --no-ff match-expander
git push origin master
Sign in to join this conversation.
No reviewers
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: mbutterick/txexpr#8
Loadingā€¦
There is no content yet.