> > 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).

> 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 :)