nvie / nox-ideas

Ideas for a new kind of programming language

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Remove Return Statement

SCKelemen opened this issue · comments

Pattern matching works because every branch of the match is an expression. If you require functions to also be expressions, then the return statement is redundant. All you need in the ExpressionStatement and DeclarationStatement.

Hi @SCKelemen! How awesome you already found this little toy playground which is really nothing more than a figment of my imagination at this point. I'm using this repo to collect ideas I like in other programming languages, and trying to imagine what this programming language would be like. No concrete plans for implementing a grammar yet, even. Just collecting and codifying some ideas.

I'm leaning towards a mix between pure/functional and pragmatic/imperative (but fully type-safe, not dynamic), and want to explore what's possible as a middle ground. So yes, pattern matching would definitely be one thing I want to borrow from FP, but I also want to keep the ability to use explicit returns, like in a fully imperative example:

func find(items: T[], pred: T -> Bool): T? {
  for (item in items) {
    if (pred(item))
      return item
  }
  return undef
}

or... a more FP equivalent:

func find(items: T[], pred: T -> Bool): T? {
  return items
    | []     -> undef
    | [x:xs] -> pred(x) ? x : find(xs, pred)
}

Both these programs would do the same thing. I agree in the latter example, the explicit return isn't strictly necessary, but in the former it is.

Hey, I've been working on a language with similar goals and a very surprisingly similar syntax..

This is your language, and I don't want to tell you what to do. I'm just sharing my opinions, in hopes that they might be helpful to you.

I disagree with you on the former. This works today in Scala.

Consider the following:

func find(items: T[], pred: T -> Bool): T? {
  for (item in items) {
    if (pred(item))
      item
  }
  undef
}

The compiler knows to always return the last expression in the block. Therefore, if we remove the return keyword, we can just use the ExpressionStatement which is a top level expression, rather than a ReturnStatement which is a top level statement that curries an Expression. You can still return early.

This is just one little detail, so I don't want to tell you to do this, but it's possible if you're curious.

Hey, I've been working on a language with similar goals and a very surprisingly similar syntax..

Do you have some public resources I could read or take a look at? Very interested to learn more about your ideas.

This is your language, and I don't want to tell you what to do. I'm just sharing my opinions, in hopes that they might be helpful to you.

Very much appreciated!

One of the things I don't want to give up on are side-effects, although I want to discourage them as much as possible. Out of curiosity, how would side-effects work with this? For example,

func find(items: T[], pred: T -> Bool): T? {
  for (item in items) {
    log('current item', item)
    if (pred(item))
      item
  }
  undef
}

How would you distinguish the log(...) expression statement from the item expression statement? Would this not "return" the log() call's return value, whatever that would be?

We have detected this issue has not had any activity during the last 60 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better collaboration environment for all. Thank you for your continued involvement and contributions!