-
Notifications
You must be signed in to change notification settings - Fork 3
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
Q: treat result
as a normal variable?
#14
Comments
result
as an injected variable?result
as a normal variable?
But result's declaration is accessible via |
Yes, that's where I get the Also I saw some comments about wanting to require |
Removing the special-casing makes some sense to me. What's the harm in it? |
Well we need to patch the compiler and it's not clear how to access |
Looks like it prepends a |
I am not sure. However, there are use-cases where you want an easy way to access the |
I like this RFC; this is also related: nim-lang/Nim#14420 (comment)
and this nim-lang/Nim#16002 (comment)
and a few other issues in which the special cased
see this: when true:
import macros
macro getTransf3(a: typed): string =
newLit a.getImplTransformed.treeRepr
proc baz(): int =
if true: 1 else: 2
echo getTransf3(baz) prints: ProcDef
Sym "baz"
Empty
Empty
FormalParams
Sym "int"
Empty
Empty
Asgn
Sym "result"
IntLit 1
Sym "result" under this RFC, we could still have links |
FWIW, CPS is currently using the result symbol from the procdef AST in order to correctly identify/rewrite the result symbol in the body supplied by the user. So there's an easy place to add a test or two... |
I've been toying with writing a webassembly backend for nim for a while, and through that I'm learning more about nim, and
I noticed that the
result
variable isn't actually declared in the ast, but seems just to be special cased in the codegen.My question is: should we actually generate the ast for the declaration of
result
(and correspodingreturn result
) in some previous pass (before the codegen)?I managed to hack up
transf.nim
to add theresult
declaration intransformBody
with this:(I know this can be made shorter and the
newTree
s are probably unnecessary, andtransf
may be pretty late to do this transformation)For a proc
this generates what I believe is the correct code (using
renderTree
on the result oftransformBody
):which could then go through the normal codegen path for
nkVarSection
.I don't think this would lead to performance gains, but it would make
result
less magic and more explicit, and probably slightly simplify code generation, which to me would still make this worthwhile.Thoughts?
The text was updated successfully, but these errors were encountered: