About expanding do end expression's behavior

[stefanos82]

Since I have just deleted Discord to reduce mental noise, I have decided to open this thread to continue from where you left this conversation about expanding do end's expression behavior.

In my humble opinion, you have a couple of options:

• either introduce a new operator, such as <~ or
• introduce a new keyword for this particular mechanism only, such as emitexpr.

[edubart]

either introduce a new operator, such as <~ or

It best to use a keyword, it's more clear.

introduce a new keyword for this particular mechanism only, such as emitexpr.

Didn't click with me, list of possible of replacing return keyword of do expressions with some new keyword:

• returneval or evalreturn
• returndo or doreturn
• returnexpr or exprreturn
• yieldexpr
• retexpr

Lot of ugly options, the motivation behind the change is to allow to allow returning from function inside do expressions, so this can be used with expression macros, allowing it to do more interesting things.

[stefanos82]

Can you provide an actual example of this case? It would help a lot to be honest with you.

[MuhammedZakir]

I like yieldexpr more than all the ones suggested in this thread.

[edubart]

I just thought about a option without introducing new keyword (do end) is already wrapped around parenthesis, I could also wrap return a into (return a):

local i = 0
local a = (do
  if i == 1 then
    (return 'one')
  else
    (return 'two')
  end
end)

Although feels odd, but at least no new keywords.

[stefanos82]

Hmm...as long as it does not become LISP this way 😄

local i = 0
local a = (do
  if i == 1 then
    emit 'one'
  else
    emit 'two'
  end
end)

it does not look that bad to be honest with you...unless you prefer:

local i = 0
local a = (do
  if i == 1 then
    reflect 'one'
  else
    reflect 'two'
  end
end)

In emit's case, we are emitting the message that represents the condition we are validating input for, whereas in the reflect's case, we simply reflecting the end result of validated input; in this case we did so as string message, but it could be anything else we would like to.

[edubart]

These keywords emit and reflect are too common, the problem of adding new common keywords is that makes user code unable to use them, I use emit keyword lot in the Nelua compiler example, also in some Nelua libraries like json from nelua-batteries already uses emit. And reflect is already used in my ray tracing library, to reflect rays.

[Andre-LA]

Two options that came in mind:

evalscope and evalresult:

local i = 0
local a = evalscope
  if i == 1 then
    evalresult 'one'
  else
    evalresult 'two'
  end
end

[stefanos82]

These introduces two new keywords instead of one...

@edubart what's the hesitation behind the use of yield?

Update: Oh shoot...I forgot about coroutine.yield(); this could lead to unnecessary confusion.

[edubart]

This is a interesting option, maybe I would just change evalresult to evalreturn. The evalscope and evalreturn are uncommon keywords, and should not introduce many problems for usual user code.

[codehz]

Idea: Implement algebraic effect, so they can be implemented as normal function call(or look like)
See https://github.com/koka-lang/libhandler (it has a lot of overhead if implemented as c library due to lack of optimization)
(However it requires lambda(with capture) feature)

[stefanos82]

This would over-complicate the language and will deviate from Nelua's original mission which is simplicity and easy to use.

[stefanos82]

Does this make sense as keyword?

local i = 0
local a = (do
  if i == 1 then
    answer 'one'
  else
    answer 'two'
  end
end)

I have also tried with

local i = 0
local a = (do
  if i == 1 then
    reply 'one'
  else
    reply 'two'
  end
end)

and looks decent too...

[Andre-LA]

If I understood correctly from discord discussion, (do end) can't be used, but if I'm wrong then indeed using this syntax to open a statement expression would be a good option, seems that it also used on Fennel.

[edubart]

(do end) can still be used, but introducing a second keyword is an option if it makes the syntax more clear and pleasant.

[ghost]

What if instead of a keyword we just use () 🤔
For Example:

local i = 2
local s = (
  if i == 1 then
      return 'one'
  elseif i == 2 then
      return 'two'
  else
      return 'other'
  end)

[edubart]

Maybe it is possible, I can't think of any syntax ambiguities of this at this moment, would have to investigate further, but this does not solve the problem of replacing return keyword with something else, also this syntax would make harder to code syntax highlighters.

[stefanos82]

@edubart what is the limitation you have with the use of return?

One thing in Rust that confused me initially but then thought it made absolute sense was the use of "naked" values as part of expression:

fn main() {
    // variable binding
    let x = 5;

    // expression;
    x;
    x + 1;
    15;
}

Maybe this could work for (do end)'s case?

local i = 0
local a = (do
  if i == 1 then
    'one'
  else
    'two'
  end
end)

[edubart]

Naked expressions is a bad idea in languages without semicolons separators ;, because things like the following is ambiguous:

return
f() -- last expression

the above should be parsed as return f() or return; f() ? For instance Lua/Nelua will parse as return f().

[stefanos82]

So, in other words an evalexpr is needed to return the desired result in each condition?

[edubart]

Yes, some keyword is needed before the actual expression.

[stefanos82]

I have a better propose if you don't mind:

Old proposed way:

local i = 0
local a = (do
  if i == 1 then
    (return 'one')
  else
    (return 'two')
  end
end)

New shorter way that makes sense at least with the aforementioned example:

local i = 0
local a = evalexpr(i == 1 and 'one' or 'two')

[ghost]

It's interesting but hard to read in my opinion

[stefanos82]

It's directly taken from Lua (let's call it ternary operator), only with the addition of evalexpr().

We could also introduce its sibling that test such expressions during compile-time, like C++'s constexpr, but that's another story.

[stefanos82]

@edubart is this the expected behavior for the following code?

require 'io'

do
  local i = 0
  local a = (do
    if i == 0 then
      return 'zero'
    end
  end)
  io.printf("i = %d, a = %s\n", i, a)
end

Why am I forced to use an else clause as well in order to make it work?

require 'io'

do
  local i = 0
  local a = (do
    if i == 0 then
      return 'zero'
    else
      return 'unknown' 
    end
  end)
  io.printf("i = %d, a = %s\n", i, a)
end

[edubart]

Why am I forced to use an else clause as well in order to make it work?

Because the last return expression is missing, what would be the value of a if i == 0 fails?

[stefanos82]

nil in this case, but logically behind the scenes (do end) should have been a <noinit> annotation for this exact reason to not set any value upon failure.

[stefanos82]

Isn't (do end) supposed to behave like status, value = (do end) and on failure, status would report the appropriate message accordingly?

So on success is true, 'zero' and in my case on failure would have been false, <noinit>, whatever the <noinit> message should be.

[edubart]

I've decided to not introduce any new keyword, the in keyword will be used for the return intent in do expressions, thus soon this will be the new syntax:

local i = 0
local a = (do
  if i == 1 then
    in 'one'
  else
    in 'other'
  end
end)

Rationale:

1. The in keyword is already available and free to be used for other statement purposes other than for loops.
2. There is some suggestion going on using in keyword for statement in expressions for Lua at http://lua-users.org/wiki/StatementsInExpressions . There they used let local x = 1 in x, however here in Nelua it will be (do local x = 1 in x end), because I want to avoid introducing the let keyword.
3. The in keyword can make some sense if you think with the meaning as the final expression to be feed as the input in where the expressions is going to be injected, or even as a shorthand for inject expression.

[stefanos82]

It's very confusing...please don't introduce this thing as it is 😞 it does not make sense.

[stefanos82]

I would prefer to see something like this instead

local i = 0
local a = (do
  'one' if i == 1 else 'other' end
end)

This looks cleaner though

local i = 0
local a = in (i == 1 and 'one' or 'two')

[MuhammedZakir]

Isn't returnexpr or yieldexpr much better than in? in works in a non-comlex expression like

let local x = 1
    local y = x+3
in  y / 2

However, in a do expression, where expressions can be much more complex, I think it would be a little confusing.

[edubart]

Isn't returnexpr or yieldexpr much better than in?

In terms of clarity yes, but at this moment my priority of not introducing new keywords is high.

in works in a non-complex expression like

Most scenarios will be non complex scenarios, like your example where you have an in statement only at the end. However Nelua implementation also has this extension of allowing multiple in points over the let in idea, but this extension will be hardly used and not going to be removed because it gives some extra meta programming power. You example in the current syntax is:

(do  local x = 1
     local y = x+3
in y / 2 end)

[stefanos82]

...whatever it works best for you mate.

If I can use already existing methodologies to produce the same output, then I will use those exclusively and avoid the new in mechanism because it confuses me like crazy.

[stefanos82]

@edubart can you provide an actual case you are currently dealing with that forces you to introduce a new mechanism to simplify possible restrictive behavior somehow?

[edubart]

@stefanos82

Actual case use case is to a try macro, like you can do in C/C++ language, to make easier to propagate errors, here is an example:

require 'io'

-- Macro for quick error handling.
## local function try(expr)
  local res, errmsg: string = #[expr]#
  if #errmsg > 0 then
    -- the following gets the first return type for the function the macro is currently parsing
    local R: type = #[context.state.funcscope.funcsym.type.rettypes[1]]#
    return R(), errmsg -- returns an empty value plus an error message
  end
  in res -- inject back the result of the try macro
## end

-- Read file, returns contents plus and error message.
local function readfile(name: string): (string, string)
  local file <close> = #[try]#(io.open(name)) -- if `io.open()` fails the function will return early with the error
  local contents = #[try]#(file:read('a')) -- if `read()` fails the function will return early with the error
  return contents, ''
end

-- Load multiple files, returns the contents plus an error message.
local function concatfiles3(f1: string, f2: string, f3: string): (string, string)
  local file1 = #[try]#(readfile(f1)) -- if `readfile` fails returns early with an error code
  local file2 = #[try]#(readfile(f2)) -- if `readfile` fails returns early with an error code
  local file3 = #[try]#(readfile(f3)) -- if `readfile` fails returns early with an error code
  return file1..file2..file3, ''
end

print(concatfiles3('file1', 'file2', 'file3'))

The benefit is to avoid typing lots of ifs and returns for checking each error code, this will make easier to make some libraries that needs to handle lot of errors. This is working with the latest commit.

You have seen macros like this recently in SerenityOS/serenity#10303