Block expressions

[metamorphix]

Currently, Clue does not support (first-class) block expressions.

The main challenge with introducing block expressions to Clue is how to distinguish them from table expressions.

[Markos-Th09]

We never really planned on doing this but here is a possible syntax

local result = {
  local a = 1
  local b = 2
  
  return a+b
}

local result

do
   local a = 1
   local b = 2
   result = a+b
end

[Maiori44]

Not only tables, everything else that uses {} will cause issues

if {...} {
   //...
}

what is {...}? a table? or a code block?
({}) could fix this if we allow code blocks to be wrapped in (), I guess. (that still leaves confusion between code block and table though.)

[Maiori44]

We never really planned on doing this but here is a possible syntax

local result = {
  local a = 1
  local b = 2
  
  return a+b
}

local result

do
   local a = 1
   local b = 2
   result = a+b
end

figuring out if it's a code block and not a table is the issue though.

[Markos-Th09]

The solutions to these kind of problems are heuristics. With a heuristic parser it should be able to efficiently parse and differentiate between them.

[Markos-Th09]

Also about the ambiguity, anything in the form of {...} or {a+b} and {0} is a table

[Maiori44]

Also about the ambiguity, anything in the form of {...} or {a+b} and {0} is a table

but {a=3} is also a table, but is also completely valid as a code block too

[Maiori44]

The solutions to these kind of problems are heuristics. With a heuristic parser it should be able to efficiently parse and differentiate between them.

No idea what this is lol

[Markos-Th09]

Also about the ambiguity, anything in the form of {...} or {a+b} and {0} is a table

but {a=3} is also a table, but is also completely valid as a code block too

yeah there is too much ambiguity to this. The only solution to not be ambiguous is to always require a trailing comma on single element tables

[Markos-Th09]

The solutions to these kind of problems are heuristics. With a heuristic parser it should be able to efficiently parse and differentiate between them.

No idea what this is lol

it is sort of making an educated guess

[Maiori44]

The solutions to these kind of problems are heuristics. With a heuristic parser it should be able to efficiently parse and differentiate between them.

No idea what this is lol

it is sort of making an educated guess

ah, I see

[Markos-Th09]

a hypothetical solution would be to have something like do {}

[Markos-Th09]

Or another solution is that unless it has a return it is not a block expression as returning nothing cannot be used for anything meaningful

edit: just to be specific, I mean implicitly nothing, return nil or return is a block

[Maiori44]

a hypothetical solution would be to have something like do {}

I don't like this idea myself, feels a bit too verbose

(ironic considering meta with exists)

[Maiori44]

Or another solution is that unless it has a return it is not a block expression that can be used for anything meaningful

That may be the best solution, but it would require a bunch more moving around in the code for the parser