Does any shell language have "true function"s ?

[Kenny McCormack]

IMHO, a "true function" would work like a regular function in a normal
language. Specifically:

1) It should take arguments in the normal way, rather than via the $1, $2, ...
mechanism. That is, it would be declared like:

function foo(arg1, arg2, arg3)

Note that the current method is just icky on general principles, and note
that it prevents a function from seeing the actual positional args. This
is, admitedly, rarely a problem in practice, but it's not that hard to
construct a case where it mattered.

2) It should return values in the normal way. Currently, there are only
two ways (that I know of) for a function to return a value:
a) By stdout (and caller uses $(...))
b) By the errorlevel (status, whatever you want to call it).
A true function would be called like:

x = foo(arg1, arg2, arg3)

and would get whatever was passed via the "return" statement in the
function.

So, that all said, my question is: Are there any shells that do this?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Aspergers

[Bit Twister]

On Tue, 5 Jun 2018 19:45:43 +0000 (UTC), Kenny McCormack wrote:
> IMHO, a "true function" would work like a regular function in a normal
> language. Specifically:
>
> 1) It should take arguments in the normal way, rather than via the $1, $2, ...
> mechanism. That is, it would be declared like:
>
> function foo(arg1, arg2, arg3)
>
> Note that the current method is just icky on general principles, and note
> that it prevents a function from seeing the actual positional args. This
> is, admitedly, rarely a problem in practice, but it's not that hard to
> construct a case where it mattered.
>
> 2) It should return values in the normal way. Currently, there are only
> two ways (that I know of) for a function to return a value:
> a) By stdout (and caller uses $(...))
> b) By the errorlevel (status, whatever you want to call it).
> A true function would be called like:
>
> x = foo(arg1, arg2, arg3)
>
> and would get whatever was passed via the "return" statement in the
> function.
>
> So, that all said, my question is: Are there any shells that do this?

How you are to use/call a function is dictated by whatever language
used. You want to use bash then you are forced to use bash syntax
rules to do what you want.

From what I can gleam from your requirements I can suggest this
example does what you say about using arguments to a function and
being able to get a status code. Output from this quick hack

$ t ar1 ar2 ar3
/home/bittwister/local/work/t ar1 ar2 ar3
return code is 3
result is foo: farg1, farg2, farg3

Code for the above results

#!/bin/bash
set -u

function foo ()
{
set -- $@
farg1=$1
farg2=$2
farg3=$3

echo "foo: $farg1, $farg2, $farg3"

return 3
} # end function foo


echo $0 $@
arg1=$1
arg2=$2
arg3=$3

result=$(foo "farg1" "farg2" "farg3")
echo return code is $?
echo result is $result

exit 0

[Janis Papanagnou]

Am 05.06.2018 um 21:45 schrieb Kenny McCormack:
> IMHO, a "true function" would work like a regular function in a normal
> language. Specifically:
>
> 1) It should take arguments in the normal way, rather than via the $1, $2, ...
> mechanism. That is, it would be declared like:
>
> function foo(arg1, arg2, arg3)

Personally I often use the pattern

function foo
{
arg1=$1 arg2=$2 arg3=$3
...

to achieve the semantic name coupling. Usually with the additional
syntax to define mandatory parameters and default values, as in

function foo
{
arg1=${1:?} arg2=${2} arg3=${3:-bar}
...

This pattern already provides options for a better interface, IMO,
at least in the function-INPUT-direction.

>
> Note that the current method is just icky on general principles, and note
> that it prevents a function from seeing the actual positional args. This
> is, admitedly, rarely a problem in practice, but it's not that hard to
> construct a case where it mattered.
>
> 2) It should return values in the normal way. Currently, there are only
> two ways (that I know of) for a function to return a value:
> a) By stdout (and caller uses $(...))
> b) By the errorlevel (status, whatever you want to call it).
> A true function would be called like:
>
> x = foo(arg1, arg2, arg3)
>
> and would get whatever was passed via the "return" statement in the
> function.
>
> So, that all said, my question is: Are there any shells that do this?

The short answer is that (IMO) there cannot be any _standard_ shell
that behaves that way. The return value - as you certainly know - is
a status/error code (plus signal passing) that is intended to behave
similar to commands in the Unix environment. (For non-standard shells,
maybe perl? anyone?, others might jump in.)

You already mentioned one standard way of returning "values"; $(...).

It may be noteworthy to mention that Kornshell supports name arguments
as function parameters with a typeset -n declaration, thus making it
possible to return values to a variable passed as parameter. The code

x=-13
function f
{
typeset -n a=$1
b=$2 c=$3
a=$(( b + c ))
}

f x 11 22
echo $x

will echo 33. (Of course you are generally also free to use a global
variable as return target, but that appears less clean than a named
argument.)

There's [in Kornshell] a couple more options with functions with the
concept of "discipline functions", were you could emulate something
like your desired syntax, but I'd consider that rather a hack; the
standard syntax ret=$( f a b c ) is already closer to what you seem
to prefer.

Janis

[Kaz Kylheku]

On 2018-06-05, Bit Twister <BitTw...@mouse-potato.com> wrote:
> On Tue, 5 Jun 2018 19:45:43 +0000 (UTC), Kenny McCormack wrote:
>> So, that all said, my question is: Are there any shells that do this?
>
> How you are to use/call a function is dictated by whatever language
> used. You want to use bash then you are forced to use bash syntax
> rules to do what you want.

I don't see where Kenny asked for a lesson in how to simulate functions
with arguments and a string return value in Bash, or how you came to
believe that he requires such a thing.

[Kenny McCormack]

In article <201806051...@kylheku.com>,

Indeed.

None of the other responders on this thread have shown anything remotely
resembling a clue as to what this is about.

Hint: At no time did I mention bash. In fact, I made it pretty clear that
the problem is that bash (and all other sh-type shells with which I am
familiar) doesn't do what I want.

I think most of these people just read a few words at the top, then start
firing off a response...

--
1/20/17: A great day for all those people who are sick of being told
they don't know how to spell "you're" (or "there").

[Janis Papanagnou]

Am 05.06.2018 um 23:42 schrieb Kenny McCormack:
>
> None of the other responders on this thread have shown anything remotely
> resembling a clue as to what this is about.

LOL - Kenny at his "best".

> Hint: At no time did I mention bash. In fact, I made it pretty clear that
> the problem is that bash (and all other sh-type shells with which I am
> familiar) doesn't do what I want.

You would probably prefer a pointy-guy type of response to your question
"So, that all said, my question is: Are there any shells that do this?":
which would simply be: "No." and "HTH." - Satisfied now?

And, just for the record, a hint: This is Usenet - other readers here
might find suggestions, elaborations or possibilities of approximations
to an achieved goal helpful, even if you were the one who initiated the
original post. (Only it doesn't seem to match with your persistent bad
and hostile attitude.)

Janis

[Christian Weisgerber]

On 2018-06-05, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> So, that all said, my question is: Are there any shells that do this?

I don't know, but if I wanted to research this, I would start by
looking at the rc, es, and scsh shells... All of which appear to
be obsolete and abandoned at this point.

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Bit Twister]

Well I can only suggest going back to the original post and read it
line by line.

In my stupid opinion, his IMHO line indicates he does not to have to
use the syntax demanded by whatever shell he wants to use.

You are making a poor assumption that I assumed the OP wanted a lesson
about returning a string, much less "how to simulate functions with arguments"

There was "no how to simulate functions". It is a "true function"

I posted actual code using as much of the orignal post as possible to
show is was just a simple matter of programming.

Take for example his "Note that the current method is just icky on

general principles, and note that it prevents a function from seeing
the actual positional args."

I gave the code showing how to get "actual positional args."
To me his "icky" just meant he did not like using the required syntax.

If you were to READ 2) and note "return values in the normal way" I
showed the function does return a value in a "normal way" and a status
code.

All "functions" I have ever used, return a result. Some even set a
status code indicating success or not.

a) and b) of 2) showed examples talking about $(...) and $? usage.

And right there is where I get to say "you have to use the syntax of
whatever shell is being used".

Read the Subject line very carefully. Note the "any shell language"
and "true function" words.

My code showed a "true function" which has positional arguments,
a method for retrieving them, returns a result and a status code.

Go ahead and Look at the Subject again.
Tell me, that my code does not fit within those parameters.

[Kenny McCormack]

In article <slrnphe1cq...@lorvorc.mips.inka.de>,

Christian Weisgerber <na...@mips.inka.de> wrote:
>On 2018-06-05, Kenny McCormack <gaz...@shell.xmission.com> wrote:
>
>> So, that all said, my question is: Are there any shells that do this?
>
>I don't know, but if I wanted to research this, I would start by
>looking at the rc, es, and scsh shells... All of which appear to
>be obsolete and abandoned at this point.

I seem to have a vague memory that some version(s) of ksh did this, and,
frankly, I'm surprised that Janis (who seems to be really in a**hole mode
for this thread) hasn't mentioned it yet. Of course, my memory could be
wrong.

BTW, Bit Twister is also an a******. That's the last I'll comment on that
subject.

--
Christianity is not a religion.

- Rick C Hodgin -

[Kaz Kylheku]

On 2018-06-05, Kenny McCormack <gaz...@shell.xmission.com> wrote:

> In article <201806051...@kylheku.com>,
> Kaz Kylheku <157-07...@kylheku.com> wrote:
>>On 2018-06-05, Bit Twister <BitTw...@mouse-potato.com> wrote:
>>> On Tue, 5 Jun 2018 19:45:43 +0000 (UTC), Kenny McCormack wrote:
>>>> So, that all said, my question is: Are there any shells that do this?
>>>
>>> How you are to use/call a function is dictated by whatever language
>>> used. You want to use bash then you are forced to use bash syntax
>>> rules to do what you want.
>>
>>I don't see where Kenny asked for a lesson in how to simulate functions
>>with arguments and a string return value in Bash, or how you came to
>>believe that he requires such a thing.
>
> Indeed.
>
> None of the other responders on this thread have shown anything remotely
> resembling a clue as to what this is about.
>
> Hint: At no time did I mention bash. In fact, I made it pretty clear that
> the problem is that bash (and all other sh-type shells with which I am
> familiar) doesn't do what I want.
>
> I think most of these people just read a few words at the top, then start
> firing off a response...

What if this feature could be bolted into POSIX shell syntax?

Propose the requirements.

Basically, those things which are called "functions" are basically just
internal "commands". They return text by producing a side effect, and
yield a termination status.

These could coexist with the new kind of function. It could be called
a "parameter function" or "string function".

Ordinary command syntax could be used for invoking parameter functions,
including $(...) command substitution.

Parameter functions could be defined using a function command/keyword.
Function calls would provide a check for too many or too few
arguments.

Variadic functions could exist; the trailing arguments would be
captured as a named Bash array.

Parameter functions would return a string.

When invoked interactively as a command, this string would be
printed, but not printed when invoked non-interactively.

The default return value (falling off the end with no return command)
would be an empty string.

When invoked as $(fun ...) the string would be substituted, just
like the standard output of a regular function. However, this would
take place without actual standard output capture.
Moreover, the standard output would remain unbound during the execution
of a parameter function; if fun prints something with echo or whatever,
that just goes to the original standard output (TTY, file, ...).

The return command would be extended to take multiple arguments.
It would work similarly to echo. E.g. return $foo "bar " $(blah)
would be a lot like echo $foo "bar " $(blah) except that everything
goes into a string, which is returned.

--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1

[Andreas Eder]

On Di 05 Jun 2018 at 19:45, gaz...@shell.xmission.com (Kenny McCormack) wrote:

> IMHO, a "true function" would work like a regular function in a normal
> language. Specifically:
>
> 1) It should take arguments in the normal way, rather than via the $1, $2, ...
> mechanism. That is, it would be declared like:
>
> function foo(arg1, arg2, arg3)
>
> Note that the current method is just icky on general principles, and note
> that it prevents a function from seeing the actual positional args. This
> is, admitedly, rarely a problem in practice, but it's not that hard to
> construct a case where it mattered.
>
> 2) It should return values in the normal way. Currently, there are only
> two ways (that I know of) for a function to return a value:
> a) By stdout (and caller uses $(...))
> b) By the errorlevel (status, whatever you want to call it).
> A true function would be called like:
>
> x = foo(arg1, arg2, arg3)
>
> and would get whatever was passed via the "return" statement in the
> function.
>
> So, that all said, my question is: Are there any shells that do this?

Have a look at elvish : https://github.com/elves/elvish
Maybe this is what you want?

'Andreas

[Janis Papanagnou]

Am 06.06.2018 um 01:38 schrieb Kenny McCormack:
>> [ functions with named parameters and value result ]

>
> I seem to have a vague memory that some version(s) of ksh did this, and,
> frankly, I'm surprised that Janis (who seems to be really in a**hole mode
> for this thread) hasn't mentioned it yet. Of course, my memory could be
> wrong.

If I'd be aware of such a thing I would of course have told you about it
in my previous reply. I've used ksh (ksh88/ksh93) for decades, and also
observed its evolution. To my best knowledge there wasn't such a thing
ever in original ksh. (It's of course possible that some ksh-like shell
clone might have incorporated such functions; I wouldn't know.) For the
original ksh I'm positive that you are misremembering.

As I already mentioned in my previous reply ksh *has* done significant
extensions to shell functions. Most prominent was inventing "Kornshell
functions"; functions that behave like complete shell scripts (WRT
option- and signal-handling, local variable definitions, maybe more).
Then there's the discipline functions; (to explain it only roughly)
functions that get triggered when function-associated variables are
handled. Ksh has also introduced the arithmetic command, something at
least related to (numeric) functions. And in context of ksh functions
the name-references for function parameters (where I gave an example
in my previous post). Last but not least there's the "object-oriented"
(an imperfect term, can't find a better one at the moment) extensions.
That's off the top of my head all that I recall in context of ksh and
function related issues.

I'd also like to re-emphasize that functions (in shell) are a misnomer;
they are (in Pascal terminology) more like "procedures". A term like
"command definition" would probably have fit better; "function" is very
misleading (as your post seems to show as well). In Unix/shell context
it makes sense that these "command definitions" behave as they do -
returning error codes through an implicit channel -, and don't resemble
mathematical functions. (But the misnomer is certainly unfortunate.)

One could think about an extension with an own syntax for functions
with named parameters and value result. But that would need an own
syntactical context (similar as arithmetic has $((...)) and ((...)) ).
The current shell design would make that hard, though; arithmetic is
bound to these parenthesized expressions, string handling is bound to
variable expansion mechanisms; now having functions like in awk would
not fit well in the shells' syntactical frame.

I guess we have to bite the bullet and use the existing mechanisms
with programming patterns that alleviate the "ugly" shell syntax.
(I posted an example in my previous post.) If one is doing heavy
"functional" programming it's probably better to switch to another
language than shell, or separate the tasks and combine the tools.

Janis

[applemcg]

On Tuesday, June 5, 2018 at 3:45:46 PM UTC-4, Kenny McCormack wrote:
> IMHO, a "true function" would work like a regular function in a normal
> language. Specifically:

> A true function would be called like:
>
> x = foo(arg1, arg2, arg3)
>
> and would get whatever was passed via the "return" statement in the
> function.
>
> So, that all said, my question is: Are there any shells that do this?

your question is more about syntax than semantics.

any shell, post ksh, allows this:

x="$(foo $arg1 ...)"

modulo 'cat' or 'echo' standing in for the return.

others here suggest assigning the positional parameters to local names. very few functions are long enough to require names as an aid to the reader. i've a family of functions: report_not{something} where something might be file, pipe, function, ... anything you can test for used like:

report_notfile $1 && return 1
report_notfunction $2 && return 2
report_notowner ...

you get the idea.

[applemcg]

Oops, forgot an important one: report_notargcount

used:
report_notargcount N $# Need a Logfile Name && return N

deinfed:

report_notargcount ()
{
: date: 2018-02-16;
[[ $2 -ge $1 ]] && return 1;
report_usage need at least $1 arg/s: ${*:3}
}

[Kenny McCormack]

In article <74b8395b-5b31-4a5e...@googlegroups.com>,

applemcg <marty....@gmail.com> wrote:
>On Tuesday, June 5, 2018 at 3:45:46 PM UTC-4, Kenny McCormack wrote:
>> IMHO, a "true function" would work like a regular function in a normal
>> language. Specifically:
>> A true function would be called like:
>>
>> x = foo(arg1, arg2, arg3)
>>
>> and would get whatever was passed via the "return" statement in the
>> function.
>>
>> So, that all said, my question is: Are there any shells that do this?
>
> your question is more about syntax than semantics.
>
>any shell, post ksh, allows this:

Another customer for the clue store.

--
"You can safely assume that you have created God in your own image when
it turns out that God hates all the same people you do." -- Anne Lamott

[T]

On 06/05/2018 12:45 PM, Kenny McCormack wrote:
> IMHO, a "true function" would work like a regular function in a normal
> language. Specifically:
>
> 1) It should take arguments in the normal way, rather than via the $1, $2, ...
> mechanism. That is, it would be declared like:
>
> function foo(arg1, arg2, arg3)
>
> Note that the current method is just icky on general principles, and note
> that it prevents a function from seeing the actual positional args. This
> is, admitedly, rarely a problem in practice, but it's not that hard to
> construct a case where it mattered.
>
> 2) It should return values in the normal way. Currently, there are only
> two ways (that I know of) for a function to return a value:
> a) By stdout (and caller uses $(...))
> b) By the errorlevel (status, whatever you want to call it).
> A true function would be called like:
>
> x = foo(arg1, arg2, arg3)
>
> and would get whatever was passed via the "return" statement in the
> function.
>
> So, that all said, my question is: Are there any shells that do this?
>

It may be time for you to consider Perl 6.

http://perl6.org/