#195 strikes again

[vendethiel]

Got bitten by this just now ... It's basically the same as #195 Just this : for get(a in b) then or for [get a in b] then Of course implicit call isn't applicable here, but I thought we may count how deep we are in [](){} (I don't think we even need to differentiate between those) before checking inFor.

[satyr]

This has always been the case (just wasn't practical before quick map). You can't use binary in/of right after for.

I thought we may count how deep we are in {} (I don't think we even need to differentiate between those) before checking inFor.

We'd need separate flags for each nesting level to handle this.

[vendethiel]

May I ask why? I thought this would not be the case as they need to be balanced anyway.

[satyr]

Because they can nest, e.g.:

for (
  for a in b => c
).p of xs => ...

[vendethiel]

Ah, right. No idea how to (cleanly) handle that (does not look like it's working currently tbh, havn't tested master yet). I was talking about depth of ()[]{} but that's definitely a failing case here :(. Except with an array which counts balance count, no idea (like =>) but that seems horrible for such an edge case.

case \for
  this@@inFor.push 0
  #...
case \(
  if @inFor
    that[*-1]++
  #...
case \)
  if @inFor
    that[*-1]--
  #...
case \in
  if @inFor
    if that[*-1] #we're in ()[]{}
      tag = \RELATION
    else
      tag = \IN
      that.pop!
  #...
### probably doesn't handle `in`/`of` in bodies. 

[goto-bus-stop]

Thanks a lot :)

[vendethiel]

gorgeous