5 ms·

I have building a toy language and about this I have wondering if is better to think in errors exactly with normal values. So, my functions are ALL like this:

by mamcx 11y ago

I have building a toy language and about this I have wondering if is better to think in errors exactly with normal values. So, my functions are ALL like this: fun sample= StdOut(Str) | StdErr(Int) do if GoodLuck() do return "Yeah!" fail 1 ie: fail is exactly like return, is just a way to split between Ok values and Err values. If the client wanna catch them: result = sample() # Get the Ok value. if the Err value is returned, then trow like in exceptions result != sample() # Get the Err value, not trow result, err != sample() #Get both What do you think?

TheLoneWolfling 11y ago
I think that I don't like your function syntax, but meh, that's kind of irrelevant. So you're basically just using exceptions as syntatic sugar for return codes. Works reasonably well, I suppose.
- mamcx 11y ago
  The syntax is no the final. I'm go after a python/julia/elixir like syntax.
  - TheLoneWolfling 11y ago
    Well, it's not there yet. That being said, I don't particularly like the overloading of `!=` there. I like the idea of a shortcut meaning "call this function and get the error value", but I wouldn't use `!=` for it. Perhaps take a page from Lua's book and use `_` as a throwaway variable. So `a = foo()`, or `a,b = foo()`, or `_,b = foo()`.
    - mamcx 11y ago
      Oh, great suggestion... and so obvious...
masklinn 11y ago
> I have building a toy language and about this I have wondering if is better to think in errors exactly with normal values. That's exactly what Rust (to keep with TFA) does. Result is not really special, its core is just enum Result<T, E> { Ok(T), Err(E) } > What do you think? That the code doesn't make sense, the result and the error should be exclusive propositions, why would you get both a result and an error when the function should return either one or the other?
- mamcx 11y ago
  > why would you get both a result and an error when the function should return either one or the other? Is modeled like unix IO (with stdin/out/err). Anyway, I think, a function/call get a value or a exception, so why not be more explicit about that?
  - masklinn 11y ago
    > Is modeled like unix IO (with stdin/out/err). Those are used for IO or user signaling, not error reporting (that's the process's return status, stderr may be used to augment it with a cause, unix utilities are centered about the status signaling correct/incorrect execution). > I think, a function/call get a value or a exception, so why not be more explicit about that? It's fine to be explicit about it (again that's what Rust does), the problem is your example isn't really explicit about it, and the second sample is downright weird. It's like Go except even more screwy. edit: in an other subthread you mention following dynamically typed languages, if we go with that and assume no type support it makes slightly more sense, but the logic is still screwy: assuming the second snippet is a function which doesn't have a result (so it can only have an error) it should use the same system as the third snippet, the faulting assignment (first snippet) is the one which should use a different syntax. And then there'a the question of what semantics you get when not assigning but just nesting expressions. An option might be to attach the decision to the call instead (kinda like Swift) e.g. the result of a regular function call would be either `error` or `result, error` (with the language enforcing that one of result and error must be nil) but by "banging" the function the error is raised instead of returned. So you'd get something along the lines of: # no result, possibly an error err = foo() # a result or an error result, err = foo() # no result, panics in case of error !foo() # a result or panics in case of error result = !foo() the language would enforce that either the error fetched or the function is bang-ed, so foo() would be illegal, because it neither receives the error nor raises on error. Not sure that's great, but it might be workable.

by mamcx 11y ago

TheLoneWolfling 11y ago

I think that I don't like your function syntax, but meh, that's kind of irrelevant. So you're basically just using exceptions as syntatic sugar for return codes. Works reasonably well, I suppose.

mamcx 11y ago
The syntax is no the final. I'm go after a python/julia/elixir like syntax.
- TheLoneWolfling 11y ago
  Well, it's not there yet. That being said, I don't particularly like the overloading of `!=` there. I like the idea of a shortcut meaning "call this function and get the error value", but I wouldn't use `!=` for it. Perhaps take a page from Lua's book and use `_` as a throwaway variable. So `a = foo()`, or `a,b = foo()`, or `_,b = foo()`.
  - mamcx 11y ago
    Oh, great suggestion... and so obvious...

masklinn 11y ago

> I have building a toy language and about this I have wondering if is better to think in errors exactly with normal values. That's exactly what Rust (to keep with TFA) does. Result is not really special, its core is just enum Result<T, E> { Ok(T), Err(E) } > What do you think? That the code doesn't make sense, the result and the error should be exclusive propositions, why would you get both a result and an error when the function should return either one or the other?

mamcx 11y ago
> why would you get both a result and an error when the function should return either one or the other? Is modeled like unix IO (with stdin/out/err). Anyway, I think, a function/call get a value or a exception, so why not be more explicit about that?
- masklinn 11y ago
  > Is modeled like unix IO (with stdin/out/err). Those are used for IO or user signaling, not error reporting (that's the process's return status, stderr may be used to augment it with a cause, unix utilities are centered about the status signaling correct/incorrect execution). > I think, a function/call get a value or a exception, so why not be more explicit about that? It's fine to be explicit about it (again that's what Rust does), the problem is your example isn't really explicit about it, and the second sample is downright weird. It's like Go except even more screwy. edit: in an other subthread you mention following dynamically typed languages, if we go with that and assume no type support it makes slightly more sense, but the logic is still screwy: assuming the second snippet is a function which doesn't have a result (so it can only have an error) it should use the same system as the third snippet, the faulting assignment (first snippet) is the one which should use a different syntax. And then there'a the question of what semantics you get when not assigning but just nesting expressions. An option might be to attach the decision to the call instead (kinda like Swift) e.g. the result of a regular function call would be either `error` or `result, error` (with the language enforcing that one of result and error must be nil) but by "banging" the function the error is raised instead of returned. So you'd get something along the lines of: # no result, possibly an error err = foo() # a result or an error result, err = foo() # no result, panics in case of error !foo() # a result or panics in case of error result = !foo() the language would enforce that either the error fetched or the function is bang-ed, so foo() would be illegal, because it neither receives the error nor raises on error. Not sure that's great, but it might be workable.