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

Behavior of for loops is not properly defined #2696

Closed
ShaiBer opened this issue May 29, 2023 · 4 comments · Fixed by #2999
Closed

Behavior of for loops is not properly defined #2696

ShaiBer opened this issue May 29, 2023 · 4 comments · Fixed by #2999
Assignees
Labels
🐛 bug Something isn't working 🛠️ compiler Compiler

Comments

@ShaiBer
Copy link
Contributor

ShaiBer commented May 29, 2023

I tried this:

for i in 1..100 {
log("${i}");
}

This happened:

I got printouts of 1..99

I expected this:

printouts of 1..100, or at least some documentation that the expected behavior is 1..99

Is there a workaround?

No response

Component

Compiler

Wing Version

No response

Wing Console Version

No response

Node.js Version

No response

Platform(s)

No response

Anything else?

I think that the behavior should be to print 1 through 100, including 100.
Or as ChatGPT puts it:

If you're referring to a mathematical notation or range, the interval 1..100 does include both 1 and 100. This is equivalent to [1, 100] in interval notation.

If you're referring to a programming language, it depends on the language. In Python, the range() function doesn't include the end value, so range(1, 100) includes 1 but not 100. However, in languages like Ruby, the range 1..100 does include both 1 and 100. Always consult the documentation or specifications for the particular language you're using.

Community Notes

  • Please vote by adding a 👍 reaction to the issue to help us prioritize.
  • If you are interested to work on this issue, please leave a comment.
@ShaiBer ShaiBer added the 🐛 bug Something isn't working label May 29, 2023
@Chriscbr
Copy link
Contributor

This could be a documentation issue - right now the current implementation of the "range syntax" in Wing is closest to the syntax in Rust, where 0..5 does not include 5, but 0..=5 does.

I think it's common for modern languages to have syntaxes for both use cases (one where you don't want to include the last element of the range, and one where you do). For some more examples, in Swift 0...5 includes 5 while 0..<5 excludes 5. (In Ruby, there are two syntaxes but it's less intuitive IMO - 0..5 includes 5, but 0...5 excludes 5).

Definitely something that can be changed if a lot of folks find it confusing - I'd be curious which syntax is most intuitive to new and existing programmers.

@ShaiBer
Copy link
Contributor Author

ShaiBer commented May 30, 2023

I think a syntax that will be compatible with the mathematical one would be most intuitive. In math syntax x..y is inclusive.

@staycoolcall911 staycoolcall911 self-assigned this Jun 19, 2023
@staycoolcall911
Copy link
Contributor

Our current impl is similar to javascript and other popular languages, let's keep it for now. I'll update the language reference doc.

// prints 0 to 99
for (let i =0; i < 100; i++) {
  console.log(i);
}

@mergify mergify bot closed this as completed in #2999 Jun 29, 2023
mergify bot pushed a commit that referenced this issue Jun 29, 2023
This PR introduces an up-to-date language reference - all wishlist/roadmap feature mentions were deleted and instead put into new/existing issues, with a link in a newly added "Roadmap" paragraph at the end of relevant sections..
All code samples (Wing and TypeScript) were tested and should successfully compile.

[Rendered version of the language reference](https://github.com/winglang/wing/blob/urib/lang-ref/docs/docs/03-language-guide/90-reference.md#1149-roadmap).

Fixes #2420 

### TODO
- [ ] I'll remove all typescript code samples in a follow-up PR

### Misc
- [x] Changed the rust debugger to debug the current open `.w` file by default (relevant contributor guide doc updated).
- [x] Small fix of a couple of tree-sitter test headlines.
- [x] Fixes #2696 - by defining the behavior of `for` loops.

### I simply removed the following spec features/requirements:
1. In 1.1.4.8 Json logging
“It is also legal to just log a json object”
2. In 1.2 Utility Functions:
“The above functions can accept variadic arguments of any type except `throw` which only accepts one argument and that is the message to be contained in the error.”
3. In 1.4 Storage modifiers:
“The name of any static data member and static member function must be different from the name of the containing class regardless of the casing.”
4. In 2.6 For:
“Type annotation after an iteratee (left hand side of **in**) is optional.”
5. In 3.2 Classes:
“Optionals are initialized to `nil` if omitted, unless the type is `nil?`, which in that case, absent initialization is a compile error.<br/>
Member function and field access in constructor with the "this" keyword before
all fields are initialized is invalid and would throw a compile error.<br/>
In other words, the `this` keyword is immutable to its field access operator `.`
before all the member fields are properly initialized. The behavior is similar to JavaScript and TypeScript in their "strict" mode.”
6. In 3.3 Preflight classes:
Scope and ID are “both overrideable by user-defined ones in constructor.”
7. In 3.8 Enumeration:
“Last comma is optional in single line definitions but required in multi line definitions.”
“`nameof` operator”
8. Entire section: 6.1.2 Shell strings
9. Entire section: 6.4 Kitchen Sink
10. Entire section: Inspiration (last section)

### Issues opened/changed to track spec completeness:
- [x] Opened issues:
	- [x] #3121 
	- [x] #3123 
	- [x] #3129
	- [x] #3139 
	- [x] #3140 
	- [x] #3142 
- [x] Changed description:
	- [x] #108 
	- [x] #2103 
	- [x] #116 
	- [x] #125 
	- [x] #128
	- [x] #129 
	- [x] #130
	- [x] #1737 

## Checklist

- [x] Title matches [Winglang's style guide](https://docs.winglang.io/contributors/pull_requests#how-are-pull-request-titles-formatted)
- [x] Description explains motivation and solution
- [ ] Tests added (always)
- [x] Docs updated (only required for features)
- [ ] Added `pr/e2e-full` label if this feature requires end-to-end testing

*By submitting this pull request, I confirm that my contribution is made under the terms of the [Monada Contribution License](https://docs.winglang.io/terms-and-policies/contribution-license.html)*.
@monadabot
Copy link
Contributor

Congrats! 🚀 This was released in Wing 0.22.43.

revitalbarletz pushed a commit that referenced this issue Jul 3, 2023
This PR introduces an up-to-date language reference - all wishlist/roadmap feature mentions were deleted and instead put into new/existing issues, with a link in a newly added "Roadmap" paragraph at the end of relevant sections..
All code samples (Wing and TypeScript) were tested and should successfully compile.

[Rendered version of the language reference](https://github.com/winglang/wing/blob/urib/lang-ref/docs/docs/03-language-guide/90-reference.md#1149-roadmap).

Fixes #2420 

### TODO
- [ ] I'll remove all typescript code samples in a follow-up PR

### Misc
- [x] Changed the rust debugger to debug the current open `.w` file by default (relevant contributor guide doc updated).
- [x] Small fix of a couple of tree-sitter test headlines.
- [x] Fixes #2696 - by defining the behavior of `for` loops.

### I simply removed the following spec features/requirements:
1. In 1.1.4.8 Json logging
“It is also legal to just log a json object”
2. In 1.2 Utility Functions:
“The above functions can accept variadic arguments of any type except `throw` which only accepts one argument and that is the message to be contained in the error.”
3. In 1.4 Storage modifiers:
“The name of any static data member and static member function must be different from the name of the containing class regardless of the casing.”
4. In 2.6 For:
“Type annotation after an iteratee (left hand side of **in**) is optional.”
5. In 3.2 Classes:
“Optionals are initialized to `nil` if omitted, unless the type is `nil?`, which in that case, absent initialization is a compile error.<br/>
Member function and field access in constructor with the "this" keyword before
all fields are initialized is invalid and would throw a compile error.<br/>
In other words, the `this` keyword is immutable to its field access operator `.`
before all the member fields are properly initialized. The behavior is similar to JavaScript and TypeScript in their "strict" mode.”
6. In 3.3 Preflight classes:
Scope and ID are “both overrideable by user-defined ones in constructor.”
7. In 3.8 Enumeration:
“Last comma is optional in single line definitions but required in multi line definitions.”
“`nameof` operator”
8. Entire section: 6.1.2 Shell strings
9. Entire section: 6.4 Kitchen Sink
10. Entire section: Inspiration (last section)

### Issues opened/changed to track spec completeness:
- [x] Opened issues:
	- [x] #3121 
	- [x] #3123 
	- [x] #3129
	- [x] #3139 
	- [x] #3140 
	- [x] #3142 
- [x] Changed description:
	- [x] #108 
	- [x] #2103 
	- [x] #116 
	- [x] #125 
	- [x] #128
	- [x] #129 
	- [x] #130
	- [x] #1737 

## Checklist

- [x] Title matches [Winglang's style guide](https://docs.winglang.io/contributors/pull_requests#how-are-pull-request-titles-formatted)
- [x] Description explains motivation and solution
- [ ] Tests added (always)
- [x] Docs updated (only required for features)
- [ ] Added `pr/e2e-full` label if this feature requires end-to-end testing

*By submitting this pull request, I confirm that my contribution is made under the terms of the [Monada Contribution License](https://docs.winglang.io/terms-and-policies/contribution-license.html)*.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working 🛠️ compiler Compiler
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

4 participants