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

Importing Infix Operators #1344

Closed
smithnormform opened this issue Apr 18, 2022 · 3 comments · Fixed by #1365
Closed

Importing Infix Operators #1344

smithnormform opened this issue Apr 18, 2022 · 3 comments · Fixed by #1365
Assignees
Labels
design needed We need to specify precisely what we want parser Issues with lexing or parsing.

Comments

@smithnormform
Copy link

smithnormform commented Apr 18, 2022

Is it possible to import infix operators (both at the type and value levels) without importing the entire module?

For example, here I define monus:

module foo::monus where 

infixl 80 ∸

type a ∸ b = max a b - b

(∸) : {a} (Cmp a, Ring a) =>
a ∸ b = if a > b then a - b else zero

The commented lines in the following fail (they also fail after adding parentheses around ∸), but importing everything succeeds:

module foo::example where

/* import foo::monus(∸)
 * x = 5 ∸ 2
 */

/* import foo::monus as monus
 * x = 5 (monus::∸) 2
 */

import foo::monus

x = 5 ∸ 2
@brianhuffman
Copy link
Contributor

Apparently Cryptol doesn't allow infix operators in import lists at the moment. It would be good to add support for this.

Haskell does support infix operators in import lists; the syntax is to put parens around the operator. I suggest we do the same. So we ought to be able to write an import declaration like this:

import Monus((∸))

or, if imported with other items from the same module, like this:

import Monus(foo, bar, (∸), baz)

@brianhuffman brianhuffman added the parser Issues with lexing or parsing. label Apr 20, 2022
@robdockins
Copy link
Contributor

Do we also need to have a way to specify the namespace? Suppose you want to import a type operator, but not a value operator that share a name (operator or otherwise); or vice-versa...

@brianhuffman
Copy link
Contributor

I'm pretty sure we don't. We should probably open a separate ticket for that, because it would make sense to implement that feature separately.

@robdockins robdockins added the design needed We need to specify precisely what we want label May 9, 2022
@qsctr qsctr self-assigned this Jun 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design needed We need to specify precisely what we want parser Issues with lexing or parsing.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants