`elseif` or `switch`? about hush HOT 9 CLOSED

Yes, implementing elseif is on my high priority list right now. It shouldn't take to much work to implement, but I have to find some time to do it.

from hush.

but I have to find some time to do it.

Fair enough. Thanks for the quick reply!

from hush.

I have two working solutions to this. At this point neither of them make any changes to the ast. They simply wrap nested if expressions as single statement blocks in the otherwise field of the outer if expression. The difference between the two solutions is a classic: One uses elseif while the other uses else if (as two separate tokens).
Is there a preference for which direction to go?

The issue with the elseif approach is that the ast doesn't directly represent the distinction, so the token is not represented in --ast or --program , which could potentially be confusing. On the other hand the implementation has a much smaller footprint then an extension to the ast would.

The issue with if is that I'm relying on source positioning (else and following if being on the same line) to identify the else if branch. I do that specifically to distinguish between the following two examples:

if <cond> then
  ...
else if <cond> then
  ...
end

if <cond> then
  ...
else
  if <cond> then
    ...
  end
end

I'm personally a fan of else if over a single keyword, and I think the same-line compromise is reasonable. It's also more clearly in-line with the ast - since I've left it as-is.

from hush.

The PR looks good! But I still feel like we should stick to not being whitespace sensitive here, so I'd insist on the elseif approach. Do you feel comfortable adjusting the PR to do so? Once again, thanks for your contribution.

from hush.

There you go: else if in #30 and elseif in #31 for comparison - feel free to reject either one.

from hush.

I vouch for the elseif approach, as Hush currently is not whitespace sensitive, and I'd like to keept it that way. If you're really inclined to else if, we could consider an implementation that works with the token sequence instead of line number. I.e., if the else token is immediately followed by an if token, then it's an else if construction. Thanks for taking you time into this issue!

from hush.

I generally agree on non-whitespace sensitivity, though I find this to be a reasonable approach. I am more inclined to else if but beyond that I also just want the feature implemented ;)

we could consider an implementation that works with the token sequence instead of line number. I.e., if the else token is immediately followed by an if token

The token sequence would always be else followed by if as whitespace isn't represented - nor should it be. I guess my question is what you mean by "immediately" in this context. I interpret it as "a single space-character between the two". But that would still mean that it's whitespace sensitive, so I'm not sure that's what you meant. I simply took the slightly more laxed approach that the number of spaces shouldn't matter.

When an if token follows an else token in the token sequence, the challenge is to detect if the parser should consume it with the else token as an else if sequence, or as a nested if expression with it's own final end token.

if <cond> then
  ...
else if <cond> then
  ...
end

if <cond> then
  ...
else
  if <cond> then
    ...
  end
end

from hush.

I've created a pull request #30. It's probably simpler to actually look at some code ;)

from hush.

Closed by #31

from hush.