help-gawk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make awk more friendly to multiline function declaration


From: Neil R. Ormos
Subject: Re: Make awk more friendly to multiline function declaration
Date: Mon, 28 Mar 2022 10:32:38 -0500 (CDT)

Wolfgang Laun wrote:
> Peng Yu wrote:

>> $ awk 'function f(x
>> , y) {

>> awk: cmd. line:2: function f(x
>> awk: cmd. line:2:             ^ unexpected newline or end of string

>> If I move the comma before y to the line of x,
>> the error disappears.

>> Adding a backslash after x also solves the
>> problem, [...]

>> Therefore, I think the grammar of awk should be
>> made more user-friendly, in this case, by
>> removing the requirement of backslash after "x"
>> when there is a comma in the next line. Does
>> this suggestion make sense?

> The current rule lets you use an unescaped
> newline after only eight distinct lexical
> symbols. You propose to add a rule to "ignore a
> newline if it occurs after an *identifier *if
> this identifier occurs *within the set of
> parentheses* used to bracket the parameter list
> after *function *followed by an identifier. Thus
> you extend a simple lexical (regular grammar)
> rule by a context-sensitive rule which needs to
> have the parser (which groups lexical tokens
> into sentences of the language) interact with
> the scanner that identifies numbers, word
> symbols and symbols. This is something that is
> against all good design rules for a compiler or
> interpreter.

> Moreover, making a "good case" for tolerance of
> line breaks in a parameter list will spur others
> to make similar "good cases" for doing the same
> within several other constructs, e.g., within
> the parentheses of an if or while statement, a
> function call, and so on. Ultimately, line end
> as a statement terminator is bound to become a
> rather hazy affair.

Gawk is already quite "tolerant" of line breaks in the instant situation.  The 
OP is aware that the error can be averted by moving the comma or adding a 
continuation backslash.  The burden on users of applying one of these solutions 
seems to be quite small, as would seem to be the benefit of making the proposed 
change to Gawk. 

However, it would be a simple matter for a user, who is dissatisfied with 
Gawk's treatment of the errant comma placement and unwilling to avail 
themselves of the obvious solutions, to write a little program to move the 
comma.  The comma mover could be run manually or as a preprocessor.  The Gawk 
manual describes a preprocessor for include directives which could be modified 
to add the comma moving feature.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]