Indirect function calls patch for gawk available
Aharon Robbins
The gawk-devel CVS tree now includes code for indirect function calls:
function foo() { print "foo" }
function bar() { print "bar" }
BEGIN {
the_func = "foo"
@the_func() # calls foo()
the_func = "bar"
@the_func() # calls bar()
}
The diff is available as a standalone patch from
http://www.skeeve.com/indirect-calls.diff
It should apply to gawk 3.1.6 or the stable branch without too much trouble.
Documentation changes are included in the patch.
Enjoy,
Arnold
--
Aharon (Arnold) Robbins arnold AT skeeve DOT com
P.O. Box 354 Home Phone: +972 8 979-0381
Nof Ayalon Cell Phone: +972 50 729-7545
D.N. Shimshon 99785 ISRAEL
Kenny McCormack
Aharon Robbins <arn...@skeeve.com> wrote:
>Hi all.
>
>The gawk-devel CVS tree now includes code for indirect function calls:
>
> function foo() { print "foo" }
> function bar() { print "bar" }
>
> BEGIN {
> the_func = "foo"
> @the_func() # calls foo()
> the_func = "bar"
> @the_func() # calls bar()
> }
>
This looks interesting. I'm sure it will be fun to play with.
But I'm curious (and I mean nothing untoward by this): What was the
motivation for this? Where did the idea come from?
(Related: I've often wondered what the motivation for the "CASE"
statement addition to GAWK was. Can you answer that?)
ggrothendieck
This looks interesting but could it not be done with the need for the
ugly @? In X(), if X had been defined as a function then it would
act as
before whereas if X were a character string then the function executed
would
be the one named by the value of X.
Ed Morton
What about "X ()", i.e. with a space between the variable and the
brackets? How would awk know that you intended X to be a variable
referencing a function and not just some text variable that happened
to contain the name of a function?
$ awk 'BEGIN{ print sprintf ("<--%s-->",1 > 0 ? 1 : 0) }'
<--1-->
$ awk 'BEGIN{ print sprintf (1 > 0 ? 1 : 0) }'
1
$ awk 'BEGIN{ X="sprintf"; print X (1 > 0 ? 1 : 0) }'
sprintf1
Ed.
Anton Treuenfels
"Kenny McCormack" <gaz...@shell.xmission.com> wrote in message
news:gl5kd1$f50$3...@news.xmission.com...
> In article <gl59sp$d69$1...@localhost.localdomain>,
> Aharon Robbins <arn...@skeeve.com> wrote:
> >Hi all.
> >
> >The gawk-devel CVS tree now includes code for indirect function calls:
> >
> > function foo() { print "foo" }
> > function bar() { print "bar" }
> >
> > BEGIN {
> > the_func = "foo"
> > @the_func() # calls foo()
> > the_func = "bar"
> > @the_func() # calls bar()
> > }
> >
>
> This looks interesting. I'm sure it will be fun to play with.
>
> But I'm curious (and I mean nothing untoward by this): What was the
> motivation for this? Where did the idea come from?
Well, suppose there is a situation in which you wish to save a large number
of input lines from multiple files and later output them together with some
additional information (an assembler listing, for example).
To save them in memory is fast but may run out of space or afoul of some
other interpreter limit, to save on disk is slow but has lots of space. If
users are given an option which, how shall this option be implemented? With
function pointers you can have two different handlers with very little
dispatch overhead. Without them you need to check a flag when saving each
line, which slows both options down.
Perhaps that is a main use - with function pointers you can implement
different behavior options by writing a bunch of highly specific functions
that do just what is needed and selecting among them via a pointer.
Otherwise you need to write larger, slower functions that check a lot of
flags to see which options are in effect (and therefore which parts of their
code to execute).
- Anton Treuenfels
Aharon Robbins
Kenny McCormack <gaz...@shell.xmission.com> wrote:
>In article <gl59sp$d69$1...@localhost.localdomain>,
>Aharon Robbins <arn...@skeeve.com> wrote:
>>Hi all.
>>
>>The gawk-devel CVS tree now includes code for indirect function calls:
>>
>> function foo() { print "foo" }
>> function bar() { print "bar" }
>>
>> BEGIN {
>> the_func = "foo"
>> @the_func() # calls foo()
>> the_func = "bar"
>> @the_func() # calls bar()
>> }
>>
>
>This looks interesting. I'm sure it will be fun to play with.
>
>But I'm curious (and I mean nothing untoward by this): What was the
>motivation for this? Where did the idea come from?
Anton gave a brief explanation: function pointers are a very
powerful way of choosing different ways to do things without
needing if-else tests. The quicksort example in the manual
provides a brief example.
It's something I'd been thinking about for a LONG time; someone
submitted a patch for similar functionality which I didn't really
like, so I finally decided to do it myself.
>(Related: I've often wondered what the motivation for the "CASE"
>statement addition to GAWK was. Can you answer that?)
It was something else from C that wasn't in awk. A volunteer who wanted
it sent me an initial implementation (his name is in the ChangeLog,
I hope), and I worked with him to get it to work the way I thought it
ought to.
Aharon Robbins
ggrothendieck <ggroth...@gmail.com> wrote:
>On Jan 20, 2:49 pm, arn...@skeeve.com (Aharon Robbins) wrote:
>> The gawk-devel CVS tree now includes code for indirect function calls:
>
> This looks interesting but could it not be done with the need for the
> ugly @? In X(), if X had been defined as a function then it would act
> as before whereas if X were a character string then the function executed
> would be the one named by the value of X.
I could have done it that way. I even did an initial version that worked
that way.
However, without the @ it looks just like a reguar function call, and I
felt that this could end up confusing the user community, since indirect
function calls would most definitely not work on other awk implementations.
Thus I felt it should be obvious at the syntactic level that something
different was going on.
ggrothendieck
> In article <92e8df89-0f53-4718-942c-fea5d0ff5...@r36g2000prf.googlegroups.com>,
>
> ggrothendieck <ggrothendi...@gmail.com> wrote:
> >On Jan 20, 2:49 pm, arn...@skeeve.com (Aharon Robbins) wrote:
> >> The gawk-devel CVS tree now includes code for indirect function calls:
> >> ...
>
> > This looks interesting but could it not be done with the need for the
> > ugly @? In X(), if X had been defined as a function then it would act
> > as before whereas if X were a character string then the function executed
> > would be the one named by the value of X.
>
> I could have done it that way. I even did an initial version that worked
> that way.
>
> However, without the @ it looks just like a reguar function call, and I
> felt that this could end up confusing the user community, since indirect
> function calls would most definitely not work on other awk implementations.
> Thus I felt it should be obvious at the syntactic level that something
> different was going on.
Most other popular dynamic languages do not have a special
notation for this so I would think most people's expectation
would be more in line with no special operator. Consider:
Python:
def f(x):
return x*x
g = f
g(3)
Javascript:
function f(x) { return x*x };
var g = f;
alert(g(3));
Lua:
function f (x) return x*x end
g = f
print(g(3))
R:
f = function(x) x*x
g = f
g(3)
R seems particularly close since it allows strings to name
functions:
f = function(x) x*x
"f"(3)
s <- "f"
s(3) # same
Manuel Collado
Do these popular dynamic languages also use an unnamed, elided operator
for string concatenation, as in AWK?
--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado
ggrothendieck
Perhaps you could elaborate.
Currently either of these programs is a syntax error in gawk:
function a { return 3 }
BEGIN { "a"() }
function a { return 3 }
BEGIN { s = "a"; s() }
so they would appear open to definition.
m.co...@domain.invalid
The following is legal:
function a(x) { return x }
BEGIN { "a"(3) }
>
> function a { return 3 }
> BEGIN { s = "a"; s() }
function a(x) { return x }
BEGIN { s = "a"; s(3) }
Illegal (undefined function s), but
function a(x) { return x }
BEGIN { s = "a"; s (3) }
is legal.
>
> so they would appear open to definition.
Both "a"(3) and s (3) imply concatenation. Relaxing the requirement for
a space before () in the second case would lead to an ambiguity (either
concatenation or a function call)
Hope this helps.
There are those who call me... Tim?
>
> The gawk-devel CVS tree now includes code for indirect function calls:
>
> function foo() { print "foo" }
> function bar() { print "bar" }
>
> BEGIN {
> the_func = "foo"
> @the_func() # calls foo()
> the_func = "bar"
> @the_func() # calls bar()
> }
>
> The diff is available as a standalone patch from
>
> http://www.skeeve.com/indirect-calls.diff
>
> It should apply to gawk 3.1.6 or the stable branch without too much trouble.
any performance hit for using @the_func?
t
ggrothendieck
Good point. At the same time it would be really nice not to have
special syntax but rather to have first class
functions that are passed around in variables in a way no different
than numbers
and variables. If s is a variable holding function f then it would be
possible
to write s(3). It wouldn't be necessary to write @s(f) since there
would
be no ambiguity since s holds a function, not a character string
representing
a function name. The functionality that @ represents would be rarely
used. Looking
forward to that day I would rather not have @ now or other ugly perl-
like constructs
but would rather see a notation that gawk can grow into.
Using toFunction("f")(3), say, is more onerous to write at the moment
but eventually, once gawk got first class functions, it would be
hardly
used at all and more attractive in the end since it would avoid any
special syntax.
Kenny McCormack
Anton Treuenfels <atreu...@earthlink.net> wrote:
>
>"Kenny McCormack" <gaz...@shell.xmission.com> wrote in message
>news:gl5kd1$f50$3...@news.xmission.com...
>> In article <gl59sp$d69$1...@localhost.localdomain>,
>> Aharon Robbins <arn...@skeeve.com> wrote:
>> >Hi all.
>> >
>> >The gawk-devel CVS tree now includes code for indirect function calls:
>> >
>> > function foo() { print "foo" }
>> > function bar() { print "bar" }
>> >
>> > BEGIN {
>> > the_func = "foo"
>> > @the_func() # calls foo()
>> > the_func = "bar"
>> > @the_func() # calls bar()
>> > }
>> >
>>
>> This looks interesting. I'm sure it will be fun to play with.
>>
>> But I'm curious (and I mean nothing untoward by this): What was the
>> motivation for this? Where did the idea come from?
>
>Well, suppose there is a situation in which you wish to save a large number
>of input lines from multiple files and later output them together with some
>additional information (an assembler listing, for example).
I'm not doubting for a second that it can and will be useful.
Nor am I arguing against its being implemented.
TAWK has had this capability all along, and I use it frequently.
My question is deeper. It goes to the fact that quite often the
newsgroup ethos is "no, can't do that. It's not standard. It is bad,
blah, blah, blah". Note that this ethos is present here (in cla), but
not as pronounced as in certain other groups. Still, I'm always a
little surprised when features like this are added to gawk.
Aharon Robbins
There are those who call me... Tim? <menzi...@gmail.com> wrote:
>On Jan 20, 2:49 pm, arn...@skeeve.com (Aharon Robbins) wrote:
>> Hi all.
>>
>> The gawk-devel CVS tree now includes code for indirect function calls:
>
There is some, but I have tried to minimize it. Given some code like this
the_func = "foo"
for (i = 1; i <= 1000; i++)
@the_func(42) # a
@the_func(42) # b
For instance a, the indirection is evaluated once, and thereafter the call
is made without having to look at the value of the_func.
However, upon hitting b, the indirection is evaluated again.
This derives from the way things are implemented inside gawk. I may be able
to improve it, but just getting things to work the way I wanted wasn't
trivial.
Aharon Robbins
Kenny McCormack <gaz...@shell.xmission.com> wrote:
>My question is deeper. It goes to the fact that quite often the
>newsgroup ethos is "no, can't do that. It's not standard. It is bad,
>blah, blah, blah". Note that this ethos is present here (in cla), but
>not as pronounced as in certain other groups. Still, I'm always a
>little surprised when features like this are added to gawk.
Gawk---meaning I, as gawk's maintainer---have to strike a balance between
standards compliance, portability to other awk versions, providing true
power for users, and avoiding the addition of what will turn out to
be useless features that shouldn't have been added in the first place.
These constraints are often at odds with each other.
In this instance, I had been thinking about function pointers for a long
time and finally decided to "just do it". Having functions be first-class
objects in awk would be lovely, but at some point, gawk stops being "awk"
and becomes something entirely different. I would prefer to avoid that.
Thus here, I made an intentional decision to require non-standard syntax
for a feature that is otherwise syntactically indistinguishable from a
regular, _standard_, _portable looking_ function call, to make it clear
that "whoa, something only gawk can do is going on here".
It would not be hard to do away with the @. But, even though the syntax
isn't pretty, it does its job, and I'd prefer to keep indirect calls
different from direct calls.
Aharon Robbins
ggrothendieck <ggroth...@gmail.com> wrote:
>On Jan 21, 12:02 am, arn...@skeeve.com (Aharon Robbins) wrote:
>> In article
><92e8df89-0f53-4718-942c-fea5d0ff5...@r36g2000prf.googlegroups.com>,
>>
>> > ugly @? In X(), if X had been defined as a function then it would act
>> > as before whereas if X were a character string then the function executed
>> > would be the one named by the value of X.
>>
>> I could have done it that way. I even did an initial version that worked
>> that way.
>>
>> However, without the @ it looks just like a reguar function call, and I
>> felt that this could end up confusing the user community, since indirect
>> function calls would most definitely not work on other awk implementations.
>> Thus I felt it should be obvious at the syntactic level that something
>> different was going on.
>
>Most other popular dynamic languages do not have a special
>notation for this so I would think most people's expectation
>would be more in line with no special operator.
All of those languages are much newer than awk. I came at the decision from
the perspective of someone who knows awk already.
I still think it was the right decision, see some of my other posts.
But I will think about it some more.
Thanks,
Arnold
Aharon Robbins
ggrothendieck <ggroth...@gmail.com> wrote:
>On Jan 21, 5:58 am, m.coll...@domain.invalid wrote:
>
> Good point. At the same time it would be really nice not to have special
> syntax but rather to have first class functions that are passed around
> in variables in a way no different than numbers and variables.
This is true. But 1) when this happens, gawk stops being "awk", which
I think is bad, and 2) it is a real implementation headache. Just
getting the current mechanism to work wasn't easy.
There is also the fact that there is essentially no way, given how gawk
works, to make the builtin functions work the same way as user defined
functions with function pointers.
Were I to design a language from scratch, I would certainly do things
differently.
Thanks,
Manuel Collado
> [...]
> ..., I had been thinking about function pointers for a long
> time and finally decided to "just do it". Having functions be first-class
> objects in awk would be lovely, but at some point, gawk stops being "awk"
> and becomes something entirely different. I would prefer to avoid that.
>
> Thus here, I made an intentional decision to require non-standard syntax
> for a feature that is otherwise syntactically indistinguishable from a
> regular, _standard_, _portable looking_ function call, to make it clear
> that "whoa, something only gawk can do is going on here".
>
> It would not be hard to do away with the @. But, even though the syntax
> isn't pretty, it does its job, and I'd prefer to keep indirect calls
> different from direct calls.
How about a syntax like
call( "funcname", arguments...)
It seems more in the style of AWK.
Kenny McCormack
Manuel Collado <m.co...@invalid.domain> wrote:
>Aharon Robbins escribió:
>> [...]
>> ..., I had been thinking about function pointers for a long
>> time and finally decided to "just do it". Having functions be first-class
>> objects in awk would be lovely, but at some point, gawk stops being "awk"
>> and becomes something entirely different. I would prefer to avoid that.
Thanks. That is a good answer to my general query.
>> Thus here, I made an intentional decision to require non-standard syntax
>> for a feature that is otherwise syntactically indistinguishable from a
>> regular, _standard_, _portable looking_ function call, to make it clear
>> that "whoa, something only gawk can do is going on here".
>>
>> It would not be hard to do away with the @. But, even though the syntax
>> isn't pretty, it does its job, and I'd prefer to keep indirect calls
>> different from direct calls.
>
>How about a syntax like
>
> call( "funcname", arguments...)
>
>It seems more in the style of AWK.
Indeed. That is exactly how TAWK does it.
There is, in fact, both call() [with the above syntax] and calla(),
which takes an array, like:
function foo(a,b,c) {print a,b,c}
BEGIN {split("quick brown fox",A);calla("foo",A)}
ggrothendieck
IMHO that's the best suggestion so far. It seems not to interfere
with future possibilities, its intent seems obvious and its not as
compact as
@ but its not too onerous either.
By the way, the R language sort of has this. In R
call("sqrt", 16)
returns the expression sqrt(16) and then you can evaluate that
if you want the answer: eval(call("sqrt", 16))
R also has do.call
do.call("sqrt", list(16))
which takes 2 args: the name of the function and list of the arguments
and
applies the function to the arguments returning the result of the
function,
similar to calla also mentioned in this thread. One can also write:
do.call(sqrt, list(16))
Python has apply which is similar to this last usage of do.call and
also to calla which was mentioned:
apply(max, [1,2])
i.e. it takes a function, not a character string.
Steffen Schuler
> In article <gl9c76$5f9$1...@heraldo.rediris.es>,
> Manuel Collado <m.co...@invalid.domain> wrote:
>>
>>How about a syntax like
>>
>> call( "funcname", arguments...)
>>
>>It seems more in the style of AWK.
>
> Indeed. That is exactly how TAWK does it.
>
> There is, in fact, both call() [with the above syntax] and calla(),
> which takes an array, like:
>
> function foo(a,b,c) {print a,b,c}
> BEGIN {split("quick brown fox",A);calla("foo",A)}
>
These are really good suggestions. Thank you Manuel and Kenny.
I like also the TAWK-syntax with call("foo", arg1, ...) and
calla("foo", array). This seems really natural and AWK-ish.
--
Steffen Schuler (goedel) <schuler...@gmail.com>
Key ID: 0x42C5D853 / Key-server: pgp.mit.edu
Kenny McCormack
Steffen Schuler <schuler...@gmail.com> wrote:
...
>> There is, in fact, both call() [with the above syntax] and calla(),
>> which takes an array, like:
>>
>> function foo(a,b,c) {print a,b,c}
>> BEGIN {split("quick brown fox",A);calla("foo",A)}
>>
>
>These are really good suggestions. Thank you Manuel and Kenny.
>I like also the TAWK-syntax with call("foo", arg1, ...) and
>calla("foo", array). This seems really natural and AWK-ish.
I also wanted to add another bit of TAWK savory goodness.
You can do:
function foo() {local ac=argcount();for (i=1; i<=ac; i++) print i,argval(i)}
BEGIN {split("quick brown fox",A);calla("foo",A)}
which prints out:
1 quick
2 brown
3 fox
r.p....@gmail.com
wrote:
> Kenny McCormack <gaze...@shell.xmission.com> wrote:
> > In article <gl9c76$5f...@heraldo.rediris.es>,
> > Manuel Collado <m.coll...@invalid.domain> wrote:
>
> >> [...]
> >>How about a syntax like
>
> >> call( "funcname", arguments...)
>
> >>It seems more in the style of AWK.
>
> > Indeed. That is exactly how TAWK does it.
>
> > There is, in fact, both call() [with the above syntax] and calla(),
> > which takes an array, like:
>
> > function foo(a,b,c) {print a,b,c}
> > BEGIN {split("quick brown fox",A);calla("foo",A)}
>
> These are really good suggestions. Thank you Manuel and Kenny.
> I like also the TAWK-syntax with call("foo", arg1, ...) and
> calla("foo", array). This seems really natural and AWK-ish.
>
> --
> Key ID: 0x42C5D853 / Key-server: pgp.mit.edu- Hide quoted text -
>
> - Show quoted text -
Hmm. I'm not convinced. @foo(2) starts to look like perl. One of
the things I like best about gawk is the way it avoides special
characters for everything. This includes explicit typing with non-
alpha characters (again, cf. perl). I am most convinced by
ggrothendieck. call("sqrt",2) starts to look like php to me -- like
two different language designers started mixing their favorite
syntactic styles. Or worse.
If one were to permit indirection whenever a variable is used where
normally a static id would be found, then this does raise other
possibilities. Could I then expect such behavior with arrays?
arr["red"] = 1; foo = "arr"; print foo["red"]?
However, Manuel's concern about concatenation is real. Somewhere
there is a sloppy awk program written
foo = "fortran"; print foo (76+1); function foo(n) { return 0 }
and that will be sad.
I do agree it is a shame to write functions that have to go through
dozens of case/switch statements, but this is not where gawk has its
greatest performance bottlenecks. Anyway, such code can be very
readable, compared to indirection, which places semantics elsewhere
and invites very
unreadable dynamics.
So my vote is not to get used to this feature! Awk dialects all have
enviable stability because we are conservative wrt syntax evolution...
Andrew Schorr
in a text processing language such as awk, it's a great
idea to be able to deference a string value as a function
pointer. And given the implicit string concatenation operator,
I think the "@" notation is needed.
But I have a feature request on top of this: I would like to
be able to achieve array indirection as well. So, for example,
I would like this code snippet to work:
foo[3] = "hello"
print @"foo"[3]
And the output would be "hello". With both function pointers and
array indirection, one can start to do some powerful and
elegant programming.
Let me give a real-world example. We download dividend data
from multiple sources and compare the data in order to decide
how to populate our database. Let's say we are examining
the dividend data for IBM. There might be a set of N different
possible sources for the dividend data, but we may have success
in retrieving data from only a subset of those. So I would
like to have an array whose members indicate which sources
successfully returned data. And for each source, I would
like to have an array that contains the data returned.
Here's a code snippet showing what I would like to achieve:
ticker = "IBM"
for (source in datasources) {
print "Successfully retrieved data for",ticker,"from",source
@(source "_show_dividends")(@(source "_data"))
}
So, for example, if one source is Yahoo finance, then
I would populate datasources["Yahoo"] = "", and
I would populate an array named Yahoo_data with the results
returned from Yahoo, and I would like to be able to
call the Yahoo_show_dividends function with the Yahoo_data
array as an argument. As you can see, if we can have
both function and array indirection, then we can start
to do real object-oriented programming.
This is a real example of an existing application, and the
current implementation is very inelegant, since I am
forced to hardcode the various datasources in many places.
Does this make sense? Is there a better way to achieve
this?
Regards,
Andy
Aharon Robbins
>> In article <gl9c76$5f9$1...@heraldo.rediris.es>,
>> Manuel Collado <m.co...@invalid.domain> wrote:
>>>
>>> [...]
>>>How about a syntax like
>>>
>>> call( "funcname", arguments...)
>>>
>>>It seems more in the style of AWK.
>>
>> Indeed. That is exactly how TAWK does it.
>>
>> There is, in fact, both call() [with the above syntax] and calla(),
>> which takes an array, like:
>>
>> function foo(a,b,c) {print a,b,c}
>> BEGIN {split("quick brown fox",A);calla("foo",A)}
>>
>
>These are really good suggestions. Thank you Manuel and Kenny.
>I like also the TAWK-syntax with call("foo", arg1, ...) and
>calla("foo", array). This seems really natural and AWK-ish.
Actually, call and calla are harder to implement given the way gawk does
builtins than the current scheme. call as described here could be done
as a function on top of the current mechanism:
function call(func, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10)
{
return @func(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10)
}
The semantics of calla aren't clear if the subscipts aren't numeric or
have gaps or ...
I will either keep the current syntax or drop the @, but I don't
anticipate making any other changes.
Thanks to everyone for their thoughts.
Steffen Schuler
Hash: SHA1
Aharon Robbins <arn...@skeeve.com> wrote:
> In article <6trmcvF...@mid.uni-berlin.de>,
> Steffen Schuler <schuler...@gmail.com> wrote:
> [...]
>> I like also the TAWK-syntax with call("foo", arg1, ...) and
>> calla("foo", array). This seems really natural and AWK-ish.
>
> Actually, call and calla are harder to implement given the way gawk does
> builtins than the current scheme.
> [...]
> The semantics of calla aren't clear if the subscipts aren't numeric or
> have gaps or ...
>
> I will either keep the current syntax or drop the @, but I don't
> anticipate making any other changes.
> [...]
Arnold, thanks for your response.
Would you accept it, when the comp.lang.awk users define the semantics of
"calla" in a joint specification process and somebody of us (perhaps me)
would provide a clean patch implementing "call" and "calla" with this
semantics (following your decisions)?
IMHO your idea with indirect function calls is pretty good but the "@"
symbol remembers too much to Perl and Ruby. A lot of people don't
like these sigils.
- --
Steffen Schuler (goedel) <schuler...@gmail.com>
Key ID: 0x42C5D853 / Key-server: pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJf4mi+/TWb0LF2FMRAnakAJ40wHaBVPr6j3XcIENR1O9n4C/ggACdGKHJ
YUzNsmr7Vr0tb7Mm5Pmh9xQ=
=Xafp
-----END PGP SIGNATURE-----
Aharon Robbins
Steffen Schuler <schuler...@gmail.com> wrote:
>Would you accept it, when the comp.lang.awk users define the semantics of
>"calla" in a joint specification process and somebody of us (perhaps me)
>would provide a clean patch implementing "call" and "calla" with this
>semantics (following your decisions)?
No. I don't see that this adds a whole lot. Sorry.
>IMHO your idea with indirect function calls is pretty good but the "@"
>symbol remembers too much to Perl and Ruby. A lot of people don't
>like these sigils.
I will consider this.
Thanks,
Arnold
Galen
> I will either keep the current syntax or drop the @, but I don't
> anticipate making any other changes.
>
I vote in favor of the @ syntax as it's reminiscent of indirect
addressing in some assembly languages, most notably (to me) MACRO-11
and MACRO-32. I have many good memories from an earlier life during
which I wrote a lot of MACRO-11.
I've never messed with perl partly because it is so ugly. But I think
the potential uglification of gawk code by the @ syntax is at the very
worst but a small price to pay for the added expressive power it
provides.
There are those who call me... Tim?
> In article <37043846-92cc-47f9-9e78-4658a970b...@v5g2000prm.googlegroups.com>,
> >On Jan 20, 2:49 pm, arn...@skeeve.com (Aharon Robbins) wrote:
> >> The gawk-devel CVS tree now includes code for indirect function calls:
>
> >any performance hit for using @the_func?
in order to check the runtime overhead on indirect functions in gawk,
i ran a test on direct vs indirect calls in gawk 3.1.70 (see below).
in summary, there is no practical performance hit in using indirect
functions. which is a very cool result
results, below.
Enjoy!
:-)
t
################
# indirect.awk
function foo() { return "foo" }
function bar() { return "bar" }
BEGIN {
if (N) while(N--) indirect()
if (M) while(M--) direct() }
function direct() {
foo()
bar() }
function indirect() {
the_func = "foo"
@the_func()
the_func = "bar"
@the_func() }
#################
# example calls
time ../bin/gawk -f indirect1.awk -v M=100000 # only make indirect
calls
time ../bin/gawk -f indirect1.awk -v N=100000 # only make direct calls
###############
# results
indirect direct
real 0m1.764s 0m1.845s
user 0m1.096s 0m1.154s
sys 0m0.658s 0m0.657s
which are basically the same runtimes