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

to segfaults when using a variable as the upper bound #14

Open
sjl opened this issue Nov 8, 2011 · 3 comments
Open

to segfaults when using a variable as the upper bound #14

sjl opened this issue Nov 8, 2011 · 3 comments
Assignees
Milestone

Comments

@sjl
Copy link

sjl commented Nov 8, 2011

Things work fine when using a variable as the lower bound, but Potion seems to segfault when using one as the upper bound. Example:

>> n = 3, n to 5 (i): i string print.
345=> 3
>> n = 5, 3 to n (i): i string print.
[1]    79643 segmentation fault  ./potion

Am I missing something?

@ghost
Copy link

ghost commented Nov 9, 2011

This is one of many subtle issues with this program. You are not missing something.

Thanks for reporting, and feel free to fix it :).

@rurban
Copy link
Member

rurban commented Oct 4, 2013

The current workaround is to use parens for the to method call:

n = 5, 3 to (n, (i): i string print.) # => 345

I'll try to fix this special case in the compiler, so that the parens are optional.

@robotii
Copy link
Contributor

robotii commented Nov 19, 2015

The following seems to work as well:

n = 5, 3 to (n) (i): i string print. # => 345

The issue is that literal values are treated differently than names, which could be a variable or another method call.

For instance in the code

up = 2, self add up

Would be ambiguous between calling add on self with no arguments, then calling up on the result, and calling add on self with a parameter up. There is no way to fix this without making the parentheses required, or making the grammar context sensitive (i.e. checking to see if each message is a variable in the current context before deciding how to treat it.

As @rurban says, this could be special cased (just for the to method on Number), but this would only work on literals.

n = 3, m = 5, n to m (i): i string print.

could not be special cased in this way, as we currently can't decide if n is a number.

It would also prevent the use of to being used in a different manner for another object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants