> > function overloading is supported in the same way that its also supported in Bash too where you might have a function but if there is a alias of the same name that will take priority.
> I don't think it is called overloading. That's very different from having two methods with the same name and the "right one" is called based on types of passed arguments.
Yeah you're right that's not overloading. I'm not really sure why included that in my description.
> In NGS it happens in exactly one place, when main() is called. At that point command line arguments are automatically parsed based on main() parameters and passed to main().
> I don't think I understand your reasoning behind not including named parameters.
there isn't really an entry point in murex scripts so
function foobar {
out foobar
}
foobar
is no different from
#!/usr/bin/env murex
out foobar
and no different from typing the following into the interactive terminal
$ out foobar
Which means every call to a builtin, function or external executable is parsed an executed as if it has been forked, at least with regards to how parameters are just an array (actually on Windows they're not even an array. Parameters are passed just as one long string, whitespace and quotation marks and all. Which is just another example of why Windows is a shit platform). This is a limitation of POSIX (and Windows) that I decided I didn't want to work around because otherwise some parts of the language would behave like POSIX (eg calling external programs and how named parameters are passed as `--key value` style flags vs scripting functions where named parameters positional arguments).
I wasn't really interested in creating a two tier language where parameters are conceptually different depending on what's being called so I decided to make flags easy instead:
function hippo {
# Hungry hippo example function demonstrating the `args` builtin
args: args {
"Flags": {
"--name": "str",
"--hungry": "bool"
}
}
$args[Flags] -> set flags
if { $flags[--hungry] } then {
out: "$flags[--name] is hungry"
} else {
out: "$flags[--name] is not hungry"
}
}
That all said. I'm still not 100% happy with this design:
- `args` still contains more boilerplate code than I'm happy with
- murex cannot use `args` to automatically generate an autocomplete suggestion
So I expect this design will change again.
> Sounds also like potentially surprising, somewhat similar to handling exit codes. Yes, it's not per program and that's why it's better but still.
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).
> Sounds like I was not clear enough as if something is not uniform in this regard in NGS. Exceptions are not only for external programs. It just happens that external program can be called inside "if" condition; an exception might occur there.
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 :)
> 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).
> `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.
> 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`.
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")
}
> I don't think it is called overloading. That's very different from having two methods with the same name and the "right one" is called based on types of passed arguments.
Yeah you're right that's not overloading. I'm not really sure why included that in my description.
> In NGS it happens in exactly one place, when main() is called. At that point command line arguments are automatically parsed based on main() parameters and passed to main(). > I don't think I understand your reasoning behind not including named parameters.
there isn't really an entry point in murex scripts so
is no different from and no different from typing the following into the interactive terminal Which means every call to a builtin, function or external executable is parsed an executed as if it has been forked, at least with regards to how parameters are just an array (actually on Windows they're not even an array. Parameters are passed just as one long string, whitespace and quotation marks and all. Which is just another example of why Windows is a shit platform). This is a limitation of POSIX (and Windows) that I decided I didn't want to work around because otherwise some parts of the language would behave like POSIX (eg calling external programs and how named parameters are passed as `--key value` style flags vs scripting functions where named parameters positional arguments).I wasn't really interested in creating a two tier language where parameters are conceptually different depending on what's being called so I decided to make flags easy instead:
That all said. I'm still not 100% happy with this design:- `args` still contains more boilerplate code than I'm happy with
- murex cannot use `args` to automatically generate an autocomplete suggestion
So I expect this design will change again.
> Sounds also like potentially surprising, somewhat similar to handling exit codes. Yes, it's not per program and that's why it's better but still.
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).
> Same in NGS but https://github.com/ngs-lang/ngs/issues/494 :)
lol I like it :)
> Sounds like I was not clear enough as if something is not uniform in this regard in NGS. Exceptions are not only for external programs. It just happens that external program can be called inside "if" condition; an exception might occur there.
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 :)