Skip to content

Conversation

rattrayalex
Copy link

@rattrayalex
Copy link
Author

rattrayalex commented May 29, 2017

The blockType wasn't needed for this (or do-while, which already has a matching-indent requirement) so I removed it, FYI.

However, I think that's because I'd forgotten that I'd won the battle not to enforce matching :/{ in ifs, and added that requirement in try/catch, which is inconsistent. So I may need to rethink that.

@wcjohnson
Copy link

wcjohnson commented May 29, 2017

If you are willing to enforce syntax with if as well, you might not need the stack at all.

@rattrayalex
Copy link
Author

Yeah. I'm finally starting to lean that direction 😉

As you know, the thinking behind the flexibility is that the linter should enforce consistency, and the compiler permit poor style, so that while a developer is quickly iterating on code they can proceed with mismatched style and then fix it up later.

However, we don't currently have lsc-specific linting rules, and it's now looking like that might be a ways out.

So while there will probably be other language features that are permissive in the hopes of a future linter coming to the rescue, I think it might be worth just enforcing consistency at the compiler level for now, and possibly reimplementing the current behavior later.

@wcjohnson it sounds like you'd be in favor of that (you always wanted consistency enforced here anyway, IIRC) – @citycide any thoughts on this?

@rattrayalex
Copy link
Author

Actually, the stack looks necessary in cases like this anyway:

x = if a:
  if (b) {
    c
  }
else if d:
  e

where, when parsing the inner if, the else is encountered, and cannot be discarded until after the alternate if's condition (d) is parsed, and the : is seen. That could be done with an extensive lookahead, but it would be quite messy as it traverses a few methods (plus would be slower).

@rattrayalex
Copy link
Author

I'll give that a try, thanks

@rattrayalex
Copy link
Author

Err, sorry, @wcjohnson at a high level can you explain how you handled the lookahead problem there?

@wcjohnson
Copy link

The approach I outlined probably won't work; I thought about it some more and deleted the comment. I do think it can be done without lookahead but it wouldn't be that straightforward.

@rattrayalex
Copy link
Author

Hmm, k. I think I'll continue to use the stack but might still enforce : consistency.

@rattrayalex
Copy link
Author

(FYI, I have to head out for the day soon and likely won't finish before then)

@rattrayalex rattrayalex force-pushed the try-blocks-aligned branch from 22fa5bb to a64557c Compare June 1, 2017 01:34
@rattrayalex
Copy link
Author

Updated, now enforces matching : behavior in both if and try

@rattrayalex
Copy link
Author

Will merge tomorrow unless anyone has concerns

@wcjohnson
Copy link

I think this is the right way to go, no objections here.

@rattrayalex rattrayalex merged commit cbb6ae5 into lightscript Jun 1, 2017
@rattrayalex rattrayalex deleted the try-blocks-aligned branch June 1, 2017 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants