Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative Syntax #14

Open
thysultan opened this issue Dec 24, 2019 · 7 comments
Open

Alternative Syntax #14

thysultan opened this issue Dec 24, 2019 · 7 comments
Labels

Comments

@thysultan
Copy link

In an effort to reduce the amount of new keywords this would pose to introduce (effect, handle and resume), the following can serve as a possible alternative, piggybacking on the return keyword.

try {
	print(return < 'ask_name')
} return (type) {
	switch (type) {
		case 'ask_name': return > 'Arya Stark'
	}
}

Where < and > respectively represent the direction of data flow.

@luizperes
Copy link
Collaborator

luizperes commented Dec 24, 2019

Hi @thysultan, I am not so sure that would work, have you tried it?

both operators > and < are already implemented as binary operators, meaning that in the JS syntax they expect an expression in both lhs and rhs, e.g. expr < expr. Also, both cases above (fn call for print and case statement) expect an expression, and I am not so sure return < 'ask_name' and return > 'Arya Stark' would eval to an expr since return is a statement, and it will probably be ambiguous to treat it both as a statement and expression.

Finally, remember that JS also doesn't need ;, so when you write:

try {
} return (type) {
}

You are actually writing:

try {
} // no catch nor effect handler

return (type);

{
  // escoped block
}

@lukeed
Copy link

lukeed commented Dec 24, 2019

If nothing else, the syntax should be

try {
  // ...
} handle (effect) {
  // ...
}

So that there aren't any implicit/phantom variables in the code. The current syntax also makes effect conditionally a reserved word which is odd.

Similarly, everyone knows the catch deals with an error, but we still define/receive it in a declarative way.

try {
  // ...
} catch (err) {
  // err or whatever variable name i want to give it
}

@luizperes
Copy link
Collaborator

luizperes commented Dec 25, 2019

Totally agree @lukeed

@thysultan
Copy link
Author

thysultan commented Dec 25, 2019

On the issue of return (type); that should be a non-issue since try... is always coupled with a secondary block?

Throwing other suggestions on the wall:

try {
	yield 'ask_name'
} catch* (type) {
	switch (type) {
		case 'ask_name': yield 'Arya Stark'
	}
}

The keyword catch in catch* will be sub-leased like function is for function*.

@taylor-cedar
Copy link

@luizperes I don't think this is accurate.

try {
} // no catch nor effect handler

return (type);

{
  // escoped block
}

You can even try it in your browser. It doesn't work. try always has a secondary block catch or finally. so try/return would work, since it's not currently valid syntax. I don't think it's a good idea though because return is really confusing.

@luizperes
Copy link
Collaborator

True that @thysultan and @taylor-cedar

@reverofevil
Copy link

@lukeed Conditional keyword are fine. We already have some, like async.

const async = 1; // OK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants