Comment by ilyash | Hacker News Reader

Comment by ilyash | Hacker News Reader

Parent Full thread

> there isn't really an entry point in murex scripts

I have a nice trick in NGS for that. Under the idea that "small scripts should not suffer", script is running top to bottom without "entry point". However, if the script has defined main() function, it is invoked (with command line arguments passed).

Example - https://github.com/ngs-lang/nsd/blob/afe0cad5e506ec4ee2fa924...

> `args` still contains more boilerplate code than I'm happy with

Is there anything preventing you to have exactly the same functionality but with syntactic sugar that it looks like parameters declaration? (Just to be clear, keeping all the ARGV machinery).

Something like (assuming local variables are supported; if not, it could still be $args[Flags] etc):

  function hippo(name:str, hungry:bool) {
    if { $hungry } then {
      out: "$name is hungry"
    } else {
      out: "$name is not hungry"
    } 
  }

> I don't see how that's surprising because it's literally the same thing you were describing with NGS (if I understood you correctly).

Yes it is almost the same in NGS with regards to exit codes, which you preferred not to do in Murex. On the other hand, checking stderr looks very similar to knowing about exit codes and here you decided to go for it. I'm puzzled why. It is somewhat fragile, like knowing about exit codes.

> It was me who was unclear as I assumed you meant it was the same error handling for builtins and functions too (as is also the case with murex). I just meant the "reality of handling forked executables" as an example rather than as a commentary about the scope of your error handling :)

Here I lost you completely but I hope it's fine :)

In NGS, exception handling is used throughout the language, consistently, well at least I hope it is.

From what I understood - same in Murex.

> Is there anything preventing you to have exactly the same functionality but with syntactic sugar that it looks like parameters declaration? (Just to be clear, keeping all the ARGV machinery).

> Something like (assuming local variables are supported; if not, it could still be $args[Flags] etc):

> example code

oooh I like that idea. Thank you for the suggestion.

> Yes it is almost the same in NGS with regards to exit codes, which you preferred not to do in Murex. On the other hand, checking stderr looks very similar to knowing about exit codes and here you decided to go for it. I'm puzzled why. It is somewhat fragile, like knowing about exit codes.

No, murex still checks for exit codes. Essentially a program is considered successful unless the following conditions are met:

  + exit code is > 0
  + STDERR in ('false', 'no', 'off', 'fail', 'failed')
  + or []byte(STDERR) > []byte(STDOUT)

The exit code is self explanatory

STDERR messages are useful for functions that return a message rather than exit code. Particularly inside `if` blocks, eg

  = 1 == 2 -> set math
  if { $math } then { out: $math } else { err: $math }

will return `false` to STDERR because $math == "false" (ie `= 1 == 2` will return "false")

As for the STDERR > STDOUT test, that covers an edge case where utilities don't return non-zero exit codes but do spam STDERR when there are problems. It's an uncommon edge case but the only time this condition is checked is when a command is evaluated in a way where you wouldn't normally want the STDOUT nor STDERR to be written to the terminal.

This also allows you to get clever and do stuff like

  if { which: foobar } else { err: "foobar is not installed }

where `if` is evaluating the result of `which` and you don't need to do more complex tests like you would in Bash to test the output of `which`.

> successful

As in not throwing exception or as in evaluates to true?

> exit code is > 0

You refused to get into specific exit codes for specific programs citing potentially surprising behavior (which I agree will sometimes be an issue).

> STDERR in ('false', 'no', 'off', 'fail', 'failed')

I correlated this with the following source code:

> if len(s) == 0 || s == "null" || s == "0" || s == "false" || s == "no" || s == "off" || s == "fail" || s == "failed" || s == "disabled" { return false

... which also has a potential for surprising behavior. (side note: appears to work on stdout, not stderr)

> or []byte(STDERR) > []byte(STDOUT)

Does that mean len(stderr) > len(stdout) ?

... also has a potential for surprising behavior. I can easily imagine a program with lots of debug/warnings/log on stderr and truthy/non-error output.

> STDERR messages are useful for functions that return a message rather than exit code.

Might be problematic because typically exit codes are used for that.

> where `if` is evaluating the result of `which` and you don't need to do more complex tests like you would in Bash to test the output of `which`.

Mmm.. Never did this. In which situation looking just at exit code of `which` is not good enough?

> if { which: foobar } else { err: "foobar is not installed }

Just to show off :) in NGS that would be:

    if not(Program('foobar')) {
        error("foobar is not installed")
    }

or sometimes just

    assert(Program('foobar'))

Reply on news.ycombinator.com