🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.misc.discuss
Article #75202

Re: gawk

#75202
From: Arnold Robbins
Date: Wed, 17 Oct 1990 23:19
159 lines
6986 bytes
In article <KPC00.90Oct5184304@JUTS.ccc.amdahl.com> kpc00@JUTS.ccc.amdahl.com (kpc) writes:
>I have some questions about gawk.  I appreciate any answers anybody
>can provide.

I guess I'll do.  David usually leaves the foot-in-mouth stuff to me. :-)

>1.  Is it faster than awk, nawk, perl?

It is faster than v7/s5 awk, and usually faster than nawk.  I haven't compared
it to perl.  That comparison is almost apples and oranges as perl does a lot
more things that awk does (by design). (No flames or awk vs. perl wars, please)

>    Does it have fewer memory (program size) limitations?

Yes.  GNU software is supposed to be only limited by the systems virtual
memory; gawk isn't completely unlimited in everything, but it's getting there.

>    How many passes through the source does it make?

One.  It may make many passes over the internal representation, but it only
reads the source program once.

>2.  Is it easily modifiable?

I think so.  Others have hacked on gawk some.  It has certainly gotten
easier to deal with as things have moved along.

>    How does it compare to nawk?

Can't answer this one, haven't looked at nawk source.

>    How easy will it be to add some operators,

Depends on how skilled you are with yacc and grammars and such. Be sure
your operators are well defined on strings, numbers, and combinations
thereof, and that you know what you're doing with the precedence.  Awk is
not as simple as it looks.

>    a few built-in functions,

Quite easy, depending upon what you want them to do.

>    and function pointers?

Probably hard.  I find that idea less useful than adding a more general
"eval" statement to awk.  (Not that trivial, mind you.)

>    How easy will it be to add a C call function?  (Ah, now you see
>    why I'm asking these questions :-).)

You can add built-in functions 'til the cows come home that just package
up their args, call the C function, and then returns the value.  Take a look
at the implementation of system, for instance.  This is easy.

> How about some kind of
>    dynamic linking and calling (I presume that this is no big deal on
>    gawk's side of things)?

That seems a lot harder, grungier, and certainly unportable.  Perhaps you
should take a look at ELK (?) or one of the other embedded language sort of
schemes instead of trying to hack up gawk to do dynamic linking.

>    How easy will it be to add some C++-style default argument values
>    for variable-argument built-in functions?

Medium hard.  It would require a grammar change as well as hacking on
the way functions are stored and called.  I don't see the value, particularly,
as unused parameters are automatically initialized to 0/the null string.

>    How easy would function overloading be to implement?

Quite hard.

>    How about overloading of built-ins?

Also hard.  Again, I think you're taking the wrong approach.  If you want
C++, get g++ or cfront.  Simply add more built-ins, awk doesn't have that
many.

>    How easy will it be to add a require/provide and/or an autoload facility?

Seems messy to me.  With gawk's use of multipe -f options and the AWKPATH
environment variable, it is easy to have library functions stored off in
a library directory somewhere.  This should give you a lot of what you need.
Especially since each function can have its own BEGIN and END blocks.

>    How easy will it be to deallocate one program's memory
>    and to load another in its place?

Messy.  Gawk really isn't organized along the lines that would make such
a thing cheap.  A quick hack might be to steal the code out of sendmail
for freezing/loading the config file and trying to get gawk to do the same
thing.

In general, I don't think the payoff is worth it.  The run time is going
to be heavily dominated by the parse tree traversal (i.e. program execution)
over the data.  The time saved in not having to build the parse tree will be
trivial in comparison to the time spent processing the data.  Effort would
be better spent optimizing the traversal, and/or optimizing the parse tree
after it's built but right before execution begins (e.g. constant folding,
loop-invariant code motion, etc).

>2.5 Is there a rewind or a skip, or an ungetline (IMHO a vacancy in
>    nawk)?

With getline, you can close the file you've been reading from and then
start doing getlines on it again.  As input can and often does come
from a pipe, rewinds don't make a lot of sense, and seeks even less so,
since input is usually in terms of lines.

>3.  Is there a compiler or a gawk to C translator?

ATT has an awk to C translator in the Toolchest.

>    Is there one in the works?

Not for gawk at the moment.  It's on our to-do list, but way down at the
bottom as it's a relatively major project.

>    How easy would it be to do a byte-compile style operation?

Probably pretty easy.  This is one of the suggested improvements in the
manual, and if you're serious about it, please get in touch with us.

>    Are there software development tools to go along with it?

There is some limited internal debugging support that could use improvement.
Otherwise, all you need is make, bison or yacc, and a C compiler.

>    Is there an emacs gawk-mode?

I don't know.  I don't (yet) use emacs.

>4.  Has it been ported to UTS (a big mainframe UNIX)?  Has it been
>    ported to HP-UX?

I believe but won't promise that the answer is yes to both.  It should come
up very easily on any System V based system.

>5.  Is its author listening?

At least one of them is... :-)

>6.  Where can I get it _using email_?

Use one of the e-mail ftp servers to get it from prep.ai.mit.edu, or 
uucp from Ohio State.

>I don't read this newsgroup; please let me know by email if this is an
>inappropriate place to ask these questions, and email any replies if
>possible.  I didn't see a gnu.misc, so I presume that this is OK.

Now he tells me. :-)  I'll email him a copy, but I think this is of enough
general interest to post too.
-- 
Arnold Robbins				AudioFAX, Inc. | Laundry increases
2000 Powers Ferry Road, #200 / Marietta, GA. 30067     | exponentially in the
INTERNET: arnold@audiofax.com Phone:   +1 404 933 7612 | number of children.
UUCP:	  emory!audfax!arnold Fax-box: +1 404 618 4581 |   -- Miriam Robbins
Technical Details
Message-ID: <271@audfax.audiofax.com>
Path: arc1-ca.pugleaf.net!gmdzi!unido!isaak!escher!nadia!smurf!ira.uka.de!sol.ctr.columbia.edu!emory!audfax!arnold
References: <KPC00.90Oct5184304@JUTS.ccc.amdahl.com>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 1025b4,88bbe2f8ffbd2f8
X-Google-Attributes: gid1025b4,public
X-Google-ArrivalTime: 1990-10-17 16:19:22 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!isaak!escher!nadia!smurf!ira.uka.de!sol.ctr.columbia.edu!emory!audfax!arnold
From: arnold@audiofax.com (Arnold Robbins)
Newsgroups: gnu.misc.discuss
Subject: Re: gawk
Message-ID: <271@audfax.audiofax.com>
Date: 17 Oct 90 23:19:22 GMT
References: <KPC00.90Oct5184304@JUTS.ccc.amdahl.com>
Distribution: gnu
Organization: AudioFAX Inc., Atlanta
Lines: 159
Posted: Thu Oct 18 00:19:22 1990