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

For loop for arrays #1753

Merged
merged 53 commits into from
Aug 9, 2022
Merged

For loop for arrays #1753

merged 53 commits into from
Aug 9, 2022

Conversation

pmqtt
Copy link
Contributor

@pmqtt pmqtt commented Jul 26, 2022

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!

explorer/ast/statement.h Outdated Show resolved Hide resolved
explorer/ast/statement.h Outdated Show resolved Hide resolved
body_(body) {
Nonnull<Arena*> arena = new Arena();
auto index_name =
arena->New<IdentifierExpression>(source_loc, "$yy_forloop");
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

explorer/interpreter/type_checker.cpp Outdated Show resolved Hide resolved
explorer/testdata/for/for-loop.carbon Outdated Show resolved Hide resolved
explorer/testdata/for/for-loop.carbon Outdated Show resolved Hide resolved
explorer/testdata/for/for-loop.carbon Outdated Show resolved Hide resolved
@pmqtt
Copy link
Contributor Author

pmqtt commented Jul 28, 2022

Thanks for the review... I should think again, how to implement this...

@@ -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";
Copy link
Contributor

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.

Copy link
Contributor Author

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.cpp Outdated Show resolved Hide resolved
body_(body) {
Nonnull<Arena*> arena = new Arena();
auto index_name =
arena->New<IdentifierExpression>(source_loc, "$yy_forloop");
Copy link
Contributor

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
@pmqtt
Copy link
Contributor Author

pmqtt commented Jul 30, 2022

Hello folks, I have reimplement the for-loop statement.

lvalue->address(), source_array->elements()[current_index],
stmt.source_loc()));
} else {
llvm::outs() << "Failure in " << __LINE__ << "\n";
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replaced!

Comment on lines +2868 to +2869
ImplScope inner_impl_scope;
inner_impl_scope.AddParent(&impl_scope);
Copy link
Contributor

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 impls can't be nested within the for statement.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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!

Comment on lines 2870 to 2872
CARBON_RETURN_IF_ERROR(TypeCheckPattern(&for_stmt.variable_declaration(),
std::nullopt, inner_impl_scope,
ValueCategory::Let));
Copy link
Contributor

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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, solved!

Comment on lines 2878 to 2879
&for_stmt.loop_target(),
&for_stmt.variable_declaration().static_type()));
Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, solved!

@pmqtt pmqtt requested a review from zygoloid August 2, 2022 09:02
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/testdata/for/for-loop-sum.carbon Outdated Show resolved Hide resolved
explorer/testdata/for/for-loop-auto.carbon Outdated Show resolved Hide resolved
explorer/testdata/for/for-loop-auto.carbon Outdated Show resolved Hide resolved
explorer/testdata/for/for-loop.carbon Outdated Show resolved Hide resolved
explorer/data/prelude.carbon Outdated Show resolved Hide resolved
@pmqtt pmqtt requested a review from geoffromer August 5, 2022 08:03
explorer/data/prelude.carbon Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
explorer/interpreter/interpreter.cpp Outdated Show resolved Hide resolved
@pmqtt pmqtt requested a review from geoffromer August 9, 2022 08:17
Copy link
Contributor

@geoffromer geoffromer left a 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?

Copy link
Contributor

@zygoloid zygoloid left a 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.

explorer/interpreter/resolve_names.cpp Outdated Show resolved Hide resolved
@zygoloid zygoloid merged commit f754373 into carbon-language:trunk Aug 9, 2022
@zygoloid zygoloid mentioned this pull request Aug 25, 2022
@chandlerc chandlerc added the explorer Action items related to Carbon explorer code label Jan 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
explorer Action items related to Carbon explorer code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants