-
Notifications
You must be signed in to change notification settings - Fork 367
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
Feature: Simplify Fn args and support positional only args #1975
Feature: Simplify Fn args and support positional only args #1975
Conversation
There are a lot of other PRs in the pipeline right now. Let's get those in before investing too much in a change this big. |
My thought too, just wanted to get this out there early since it would be a big change. |
Making this change might be a good opportunity to rename |
It does decouple |
Yeah, whereas I think |
I would be happy with changing to |
I don't have a strong opinion either way; speaking strictly for my own personal opinion, I'm more familiar with python than any lisp-family so |
It's still easy to typo |
Can confirm, I have indeed done that several times. |
I would prefer to keep I know this is different from python, but in my mind it just makes more sense. In general, I think that it makes sense for all |
Python itself seems to be inconsistent with how you has to define things: you use Having |
I think @peaceamongworlds makes a good point. Changing to There doesn't seem to be any pushback against the actual changes to the argument processing logic, can I go ahead and start migrating the rest of the repo over to the new fn args? |
Actually, I'd advocate changing
Yep, no reason to let our bikeshedding of the name stand in the way of that work. |
3106429
to
e3e21dd
Compare
This migrates everything. HyDomain hasn't been updated with this or the tag macro changes so the docs will be broken until i can fix that. This shouldn't be merged until then. |
b8a9bbd
to
a5319e9
Compare
I have a fix for both tag macros and the new arg format in |
Isn't You don't seem to allow default arguments for positional-only parameters, but Python does. The pattern Are you sure you want Also, Python forbids
I think this can be enforced by changing the pattern. I'll look at the other commits once you've reorganized them. |
Turns out it is, removed from
fixed
done
Tried nesting it in the previous form, but it created a lot of funky edge cases with how funcparser lib formed them together. Simplified the form to be more explicit instead.
With how |
c135462
to
18512c9
Compare
Nice, looking better. Can you break some of the longer lines? Aim for a line length of 70 or 80 characters. 90 or more is too long unless you're shoving something uninteresting onto the end there. I think Why are you using
You're writing out the same function twice here. A more concise approach would be:
I think you can say just |
Looks like tests failing because of |
18512c9
to
95deef5
Compare
Done
Done
you right. in adding this though I ended up changing if any(dropwhile(lambda x: x,
(isinstance(x[1], HySymbol) for x in posonly + args))):
raise self._syntax_error(None, "non-default argument follows default argument") to is_positional_arg = lambda x: isinstance(x[1], HySymbol)
invalid_non_default = next(
(arg
for arg in dropwhile(is_positional_arg, posonly + args)
if is_positional_arg(arg)),
None
)
if invalid_non_default:
raise self._syntax_error(
invalid_non_default[1], "non-default argument follows default argument"
) which is obviously more verbose, but we get nicer syntax errors about which arg is the culprit ie: File "<stdin>", line 1
(defn test [a / [b 1] c])
^
hy.errors.HySyntaxError: non-default argument follows default argument
Done |
Sounds good. So you want to change |
hydomain has been updated. tested it on this branch and things look good |
Can you reorganize the commits to separate out more substantive changes (like the edits to the body of |
As it stands now Hy works almost seamlessly with Clojure editor modes. Given the philosophy of “lipstick on Python”, I don’t see why the lipstick should be nude-colored rather than Clojure-colored.
Also: while it’s true that one should expect discontinuities for a project like Hy, do the benefits of breaking older code (in the case of `defn`, apparently aesthetic) outweigh the costs?
Em 27 de fev. de 2021 13:22 -0300, Allie Jo Casey ***@***.***> escreveu:
… I think @peaceamongworlds makes a good point. Changing to def kind of negates the reasoning for having defclass instead of just class and there's no real equivalent to defmacro to change to. The semantic unity of fn, defn, defmacro, and defclass is quite nice to have in a language, but so is sticking to the "lipstick on python" philosophy so i'm torn at the moment.
There doesn't seem to be any pushback against the actual changes to the argument processing logic, can I go ahead and start migrating the rest of the repo over to the new fn args?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Backwards compatibility isn't in scope until Hy 1.0. |
I was going to propose a 1.0 feature lock and moving to pre-releases once i'm done categorizing all the open issues to make this drive to 1.0 less painful for users. The constant breaking changes is basically a giant neon sign saying "don't use this language" which probably isn't great for Hy's adoption long term. |
Can you be more specific? There's currently one commit for the compiler changes, one for changes to |
The many trivial changes like
are what I mean by "mass syntax changes". The edits to the body of
Put the mass syntax changes in a different commit from nontrivial changes so I know what to read. |
95deef5
to
61d3516
Compare
Oh right, I forgot there were changes to certain macro parsing logic. I think this addresses everything. I'll rebase off master to get the py3.10 fix in |
61d3516
to
50814b0
Compare
Done |
Excellent work. Now I have to update all my own code (oof). |
Closes #1411
This is a quick and dirty implementation of what we were talking about in #1411. I haven't updated any tests, documentation, or core method definitions since I wanna get y'alls opinions on this before jumping into that mammoth task.
To paraphrase the discussion:
/
demarks the end of positional only arguments*
demarks the start of keyword only arguments^ann #* <sym>
collects varargs into<sym>
and also marks the start keyword only arguments^ann #** <sym>
collects keyword varargs into<sym>
^ann <sym>
demarks a positional argument^ann [<sym> <default>]
demarks a keyword argumentwith function definitions looking like this:
with the equivalent python looking like