Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename primitives for clojure compatibility #8

Closed
jar600 opened this issue May 9, 2018 · 4 comments
Closed

Rename primitives for clojure compatibility #8

jar600 opened this issue May 9, 2018 · 4 comments
Assignees
Labels
question A question for the maintainers.

Comments

@jar600
Copy link
Contributor

jar600 commented May 9, 2018

Most primitives (see builtin.clj) got their names from the Python version of metaprob. I was hesitant to change them lest we lose python compatibility. But now, having dropped that requirement, we could rename them.

For example, the arithemetic primitives are add, sub, mul, div, le, gte and so on. They could be + - * / < >= and so on.

A few other clojure inconsistencies are: length/count, tuple/vector.

More generally, there has been no overall review of the language design now that we are dropping the Python compatibility requirement.

@jar600 jar600 added the question A question for the maintainers. label May 9, 2018
@vkmvkmvkmvkm vkmvkmvkmvkm added this to the POPL-ready milestone May 21, 2018
@vkmvkmvkmvkm
Copy link

Please spend time doing this soon --- before POPL.

@jar600
Copy link
Contributor Author

jar600 commented May 21, 2018

How far to go with compatibility? E.g. what about eliminating define in favor of a combination of let and letfn ?

jar600 pushed a commit that referenced this issue Jun 26, 2018
@jar600
Copy link
Contributor Author

jar600 commented Jun 26, 2018

This is mostly done. New names are available and instituted through much of the code. Old names preserved temporarily. Left infer.clj alone pending merge of #25.

@jar398
Copy link
Contributor

jar398 commented Oct 1, 2018

I'm going to close this. length is not really the same as count because count of a nonempty list has to always return 1 (only 1 subtrace key) while length has to return its length. Changing tuple to vector is a big pervasive change and should be done separately. block vs. do is discussed in #59. We talked about doing a comprehensive review and this will come again then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question A question for the maintainers.
Projects
None yet
Development

No branches or pull requests

3 participants