Rules for new function in stdlib

[CymDeveloppement]

I think it would be important to define rules to know if a new function should be integrated as a new command or not
for example a printf function, which is best, an internal command or stdlib function.

[CymDeveloppement]

I think if can be a stdlib function this should not be implemented as a command.
Is not necessary to complexify language.

[Mte90]

I think that stdlib should be like a library exposed by the language itself to do stuff more quickly and be sure that you are doing it in the right way.

To define what function we should have I looked at my script about the most common stuff I did and added them.Z
Implement them as pure Amber is more fast then writing them in Rust (or I misunderstood).

[Ph0enixKM]

Proposition of the rules

This applies only to built-ins. New mechanisms like subprocess management and so on should be added at the language level and not as standard library functions.

[blackshot]

i would add "If std suddently gone missing/unreacheable, should i still be able to use it because its essential nature to a programming lang?"

[CymDeveloppement]

Maybe you can add "is infallible ?" condition to introduce as a built-in command

[b1ek]

that would mean removing echo as a built in

[Ph0enixKM]

The infailable means "a part of POSIX standard". If we assume that, then echo is fine

[b1ek]

The infailable means "a part of POSIX standard". If we assume that, then echo is fine

i dont get it. you can't just say one thing and then claim it to mean something else

[Ph0enixKM]

@b1ek I think that it was mentioned somewhere before. If not - my apologies. But if we assume that echo doesn't exist, then are we even talking about a shell environment? Most of the environments do come with at least commands that are a part of POSIX standard. If your environment does not support echo, then you shouldn't probably even use Bash for this type of problem. Or just don't use the echo (or any built-in) command at all.

[b1ek]

that wasnt my point. what i meant is we cant have a requirement for all builtins to be infallible, at least i cant think of any bash command that cannot fail

[Ph0enixKM]

Updated proposition

New command that is commonly used can be added as built-in if ALL of the following requirements are satisfied:

• This command is used pretty often
• This command does not require any use of external or non-posix commands
• This command does not require more than one arguments
• This command does not rely on standard library
• This command is part of POSIX
• This command is non-destructive (isn't dangerous to the user)

[Ph0enixKM]

If the function already exists and gets imported then the error is reported

[CymDeveloppement]

ok, I need to give you more explanations.
In some cases, it is useful to implement your own version of the command :

1. bug
2. Security fix
3. specific usage

It is possible only with stdlib function not with built-in command.
i think it's important to consider this before implement as a built-in command
built-in command is locked.

[Ph0enixKM]

How do you define built-in commands @CymDeveloppement? Do you mean the POSIX command names or the built-into Amber commands like echo (and soon exit as it's still not a built-in command)?

The exit() function is not a built-in command. It's a standard library function

[CymDeveloppement]

Built in Amber.
#285 is about move exit from stdlib to amber built-in command

[Ph0enixKM]

@CymDeveloppement function name cannot be named the same as built-in. If we add a new builtin exit:

exit 0
exit 127

Then people won't be able to override it.

fun exit(num: Num) {
	unsafe $rm -rf /$
}

The above will no longer be possible.

[CymDeveloppement]

To clarify the discussion, I would be interested to know for you what is the interest of an amber built-in command.
I think this is not obvious

[Ph0enixKM]

Updated proposition

New command that is commonly used can be added as built-in if ALL of the following requirements are satisfied:

• This command is used pretty often
• This command does not require any use of external or non-posix commands
• This command does not require more than one arguments
• This command does not rely on standard library
• This command is part of POSIX

I think that the proposition from the above is sufficient. Do you think that continuing this conversation is fruitful? Is there anything that we should pay attention to?

[hdwalters]

CymDeveloppement wrote:

I think if can be a stdlib function this should not be implemented as a command. Is not necessary to complexify language.

In general I agree, but I believe some things do need to be builtins, for reasons of efficiency. For example, the glob expression I've implemented could be written as a standard library function, but the only way that works is to allocate and return a [Text] array containing every filename; this is not scalable for large numbers of files.

An even more extreme example is my proposed lines expression, which would have to return a [Text] array containing every line in the file; this is certainly not scalable for large files.

However, with a builtin, we can be much more efficient, by implementing a native Bash for loop, removing the need to allocate Bash arrays.

[hdwalters]

Ph0enixKM wrote:

New command that is commonly used can be added as built-in if ALL of the following requirements are satisfied:

My glob expression fulfils most of the requirements for a builtin:

[yes] This command is used pretty often
[yes] This command does not require any use of external or non-posix commands
[no] This command does not require more than one arguments
[yes] This command does not rely on standard library
[yes] This command is part of POSIX

I would also like to point out that the mv builtin command takes two arguments.

[hdwalters]

I would like to propose a clarification between builtin commands and builtin expressions:

• Builtin commands (e.g. cd, echo etc) can be run from the script root, main block or any function; and can only take a single argument without parentheses, e.g. echo "Hello world!" (although please note my point above about mv).
• Builtin expressions (e.g. glob, lines etc) can be run from within a loop or similar syntactic construct; and can take multiple arguments with parentheses, e.g. for file in glob("*.csv", "*.txt"), or for line in lines("README.md").

As an aside, one solution would be to change the syntax, and require parentheses on everything, e.g. echo("Hello world!"). This would avoid potential confusion for Amber users, though I appreciate there may be good reasons to maintain the status quo.