-
Notifications
You must be signed in to change notification settings - Fork 371
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
Consider extending Hy's .
form to accept calls
#1108
Comments
The compiler could be simplified if we keep special forms as close as possible to the Python AST. I think we should simplify the |
I just want to bump this with a few other suggestions (if it were up to me, I'd just extend My suggestions are to just treat string and integer entries in
Would be the same as
I have a macro that does this (not super cleanly) already if someone wants to play with it. It also expands method calls as originally suggested.
|
this seems reasonable and pretty easy to do by changing the definition of the -@pattern_macro(".", [FORM, many(SYM | brackets(FORM))])
+@pattern_macro(".", [FORM, many(FORM)])
def compile_attribute_access(compiler, expr, name, invocant, keys):
ret = compiler.compile(invocant)
for attr in keys:
if isinstance(attr, Symbol):
ret += asty.Attribute(attr,
value=ret.force_expr,
attr=mangle(attr),
ctx=ast.Load())
- else: # attr is a hy List
+ elif isinstance(attr, List):
compiled_attr = compiler.compile(attr[0])
ret = compiled_attr + ret + asty.Subscript(
attr,
value=ret.force_expr,
slice=ast.Index(value=compiled_attr.force_expr),
ctx=ast.Load())
+ elif isinstance(attr, Expression):
+ root, *args = attr
+ func = asty.Attribute(
+ root, value=ret.force_expr, attr=mangle(root), ctx=ast.Load()
+ )
+
+ args, funcret, keywords = compiler._compile_collect(args, with_kwargs=True)
+ ret += (
+ funcret
+ + func
+ + asty.Call(expr, func=func, args=args, keywords=keywords)
+ )
+ else:
+ raise ValueError("Bad member access")
return ret in my tests this seems to work in all the ways i expect it too. Does anyone see any reason this shouldn't be PR'd? |
I would extend the pattern, rather than generalizing it to |
Clojure's
..
can have method calls. This is especially useful when chaining accessors, for example:expands to
.
, which can also have calls:This doesn't appear to work in Hy:
The error message seems to indicate that this should work, is this a bug? And why restrict it to one item? Clojure doesn't.
This makes chaining of accessors awkward (--spy):
Although the
->
macro helps.But Hy's
.
can chain when not using callsThis makes it more like Clojure's
..
, than Clojure's.
, which can only take two arguments.The proposed extended form would look like this:
The calls could also accept arguments, as Clojure.
The text was updated successfully, but these errors were encountered: