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

User-created keywords #3593

Open
pzinn opened this issue Nov 26, 2024 · 3 comments
Open

User-created keywords #3593

pzinn opened this issue Nov 26, 2024 · 3 comments

Comments

@pzinn
Copy link
Contributor

pzinn commented Nov 26, 2024

Following #3584, compare

i1 : symbol ×

o1 = ×

o1 : Symbol

i2 : symbol ⧢

o2 = ⧢

o2 : Keyword

Why the difference? because an arbitrary list of symbols has been declared as a keyword (something that I'd rather call a binary operator, but sadly the word Binary is used for something completely different in M2. I digress.), i.e., something that's used like this:

i3 : 1 ⧢ 2
stdio:3:2:(3): error: no method for binary operator ⧢ applied to objects:
            1 (of class ZZ)
      ⧢     2 (of class ZZ)

But realistically most users are never going to use so why this symbol rather than another?
I think it'd make much more sense for users/packages to be able to define their own Keywords. Then the Core should stick to a minimal set of Keywords.
Incidentally note that new Keyword from × will not produce an error (though currently, it probably should, since the result is not what you would expect).

@pzinn
Copy link
Contributor Author

pzinn commented Nov 26, 2024

As pointed out in the comments of #3584, this also works but messes up things:

i1 : a⊗b
stdio:1:1:(3): error: no method for binary operator ** applied to objects:
            a (of class Symbol)
     **     b (of class Symbol)

i2 : getSymbol "⊗"

o2 = ⊗

o2 : Keyword

i3 : a⊗b

i4 : 

@pzinn
Copy link
Contributor Author

pzinn commented Nov 27, 2024

Some relevant remarks:

  • at the d level, there's no difference in "type" between Keywords and Symbols, they're both SymbolClosure, and class determines on the fly which is which thanks to this line in classes.dd:
     is s:SymbolClosure do if s.symbol.word.parse == parseWORD then symbolClass else keywordClass

so the difference is made using parsing information.

  • on the other hand new Keyword from xxx produces a SpecialExpr (which it probably shouldn't)
  • finally, getSymbol "⊗" creates a new symbol which is correctly determined to be a Keyword, except it doesn't have any methods associated to it (and in fact, we can't define any: error: can't assign a method for this binary operator) so it calls the dummy binary function, which is supposed to throw an error, except AFAICT err_error does nothing, so it doesn't.

@pzinn
Copy link
Contributor Author

pzinn commented Nov 28, 2024

I intend to rewrite binding.d and actors5.d which have become a mess, due to the overabundance of keywords/symbols.

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

No branches or pull requests

1 participant