-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
For loop for arrays #1753
For loop for arrays #1753
Conversation
explorer/ast/statement.h
Outdated
body_(body) { | ||
Nonnull<Arena*> arena = new Arena(); | ||
auto index_name = | ||
arena->New<IdentifierExpression>(source_loc, "$yy_forloop"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We generally try to have the parsed AST match the syntax that the user supplied, because otherwise things like error messages and trace output can get very confusing, because they're talking about code that the user can't see. We've sometimes talked about implementing some features in terms of AST rewriting, but haven't figured out a design that we're happy with.
Instead of introducing these artificial AST nodes so that they can be fed to the interpreter, my recommendation would be to have logic in the part of the interpreter that implements For
that directly does what execution of those nodes would do. For example, instead of synthesizing an AST node that calls __intrinsic_array_sz
, have code in the interpreter that directly calls .elements().vec().size()
on the array (as a side benefit, I think that means we don't need __intrinsiz_array_sz
in the first place). Does that make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok! I will remove the code and try to implement as logic in the node.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may need or want to create additional AST nodes to represent the semantics of the loop -- for example, if we have an interface for converting an arbitrary sequence into something we can iterate over. If you find that's necessary, that would be better done in type_checking.cpp when we type-check the statement, rather than here.
Thanks for the review... I should think again, how to implement this... |
Co-authored-by: Geoff Romer <[email protected]>
explorer/ast/expression.cpp
Outdated
@@ -184,6 +185,9 @@ void Expression::Print(llvm::raw_ostream& out) const { | |||
case IntrinsicExpression::Intrinsic::Dealloc: | |||
out << "delete"; | |||
break; | |||
case IntrinsicExpression::Intrinsic::ArraySz: | |||
out << "array_sz"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't consistent with the spelling you used earlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's removed!
explorer/ast/statement.h
Outdated
body_(body) { | ||
Nonnull<Arena*> arena = new Arena(); | ||
auto index_name = | ||
arena->New<IdentifierExpression>(source_loc, "$yy_forloop"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may need or want to create additional AST nodes to represent the semantics of the loop -- for example, if we have an interface for converting an arbitrary sequence into something we can iterate over. If you find that's necessary, that would be better done in type_checking.cpp when we type-check the statement, rather than here.
# Conflicts: # common/fuzzing/carbon.proto # common/fuzzing/proto_to_carbon.cpp # explorer/ast/expression.cpp # explorer/ast/expression.h # explorer/fuzzing/ast_to_proto.cpp # explorer/interpreter/interpreter.cpp # explorer/interpreter/type_checker.cpp
# Conflicts: # common/fuzzing/carbon.proto # common/fuzzing/proto_to_carbon.cpp # explorer/ast/expression.cpp # explorer/ast/expression.h # explorer/fuzzing/ast_to_proto.cpp # explorer/interpreter/interpreter.cpp # explorer/interpreter/type_checker.cpp
Hello folks, I have reimplement the for-loop statement. |
Co-authored-by: Richard Smith <[email protected]>
explorer/interpreter/interpreter.cpp
Outdated
lvalue->address(), source_array->elements()[current_index], | ||
stmt.source_loc())); | ||
} else { | ||
llvm::outs() << "Failure in " << __LINE__ << "\n"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use CARBON_CHECK
or CARBON_FATAL
as appropriate here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replaced!
ImplScope inner_impl_scope; | ||
inner_impl_scope.AddParent(&impl_scope); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should need a separate ImplScope
here, since impl
s can't be nested within the for
statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please corrent me, but isn't it so:
Block
for( x: i32 in ar) //new Block{
//new Block
}
Block
Because after the execution of the loop, x shouldn't be found in Block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another problem is that TypeCheckPattern expected a non const ImplScope, but impl_scope is const!
CARBON_RETURN_IF_ERROR(TypeCheckPattern(&for_stmt.variable_declaration(), | ||
std::nullopt, inner_impl_scope, | ||
ValueCategory::Let)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we type-check the range first, we can pass in an expected type here, which should allow us to support things like for (x: auto in arr)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, solved!
&for_stmt.loop_target(), | ||
&for_stmt.variable_declaration().static_type())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I would have expected that we want to convert the array element type of the type of the loop target, not the type of the loop target itself, here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks, solved!
# Conflicts: # explorer/syntax/lexer.lpp
Co-authored-by: Geoff Romer <[email protected]>
Co-authored-by: Geoff Romer <[email protected]>
…into for-loop-string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. @zygoloid, do you want to take another look or shall I merge it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment, otherwise looks good.
Co-authored-by: Richard Smith <[email protected]>
Hello folks,
I have the for-loop statement implements... Test Cases are in testdata/for/
Comments and suggestions for improvement are very welcome, because my implementation manipulate the AST to transform the for-loop in the aquivalent while form.
I hope it is useful und best regrads!