Re: [9fans] rc: fn name @{block}

Re: [9fans] rc: fn name @{block}

[erik quanstrom]

On Fri Mar 30 07:44:12 EDT 2012, yarikos@gmail.com wrote:
> "fn name @{block}" doesn't cause block to run in a sub-shell, although
> it accepts the syntax.
> Is it someting should not be tried, or something shoud be fixed?

you've misunderstood the current grammar.  you have defined 2 functions
name and '@' as {block}.  the binding, illustrated with parens is
	fn (name @) {block}
the production in the grammer is
	FN words brace
but since once production for words is words -> keyword, a keyword
is a valid function name.

so if you have

	fn @{echo hi, mom}

then

	ladd; fn @{echo hi, mom}		# space makes no difference
	ladd; whatis @
	fn @ {echo hi, mom}
	ladd; @
	ladd; '@'
	hi, mom

one could argue that this is a misfeature, since you can define
a function named 'for' or 'if' or '~' or '!'.  i don't currently see how disallowing
keywords in function names would be a problem, but it would
require at least 1 new production in the grammar.

note that "fn {echo bar}" is also legal, but doesn't do anything.

i've attached a change to the grammar that addresses this oddity.

- erik


----
broken! diffy -c syn.y
/n/dump/2012/0330/sys/src/cmd/rc/syn.y:29,35 - syn.y:29,35
  	struct tree *tree;
  };
  %type<tree> line paren brace body cmdsa cmdsan assign epilog redir
- %type<tree> cmd simple first word comword keyword words wordsnl
+ %type<tree> cmd simple first word nkword comword keyword nkwords words wordsnl
  %type<tree> NOT FOR IN WHILE IF TWIDDLE BANG SUBSHELL SWITCH FN BREAK
  %type<tree> WORD REDIR DUP PIPE
  %%
/n/dump/2012/0330/sys/src/cmd/rc/syn.y:81,88 - syn.y:81,88
  |	assign cmd %prec BANG	{$$=mung3($1, $1->child[0], $1->child[1], $2);}
  |	BANG cmd		{$$=mung1($1, $2);}
  |	SUBSHELL cmd		{$$=mung1($1, $2);}
- |	FN words brace		{$$=tree2(FN, $2, $3);}
- |	FN words		{$$=tree1(FN, $2);}
+ |	FN nkwords brace		{$$=tree2(FN, $2, $3);}
+ |	FN nkwords		{$$=tree1(FN, $2);}
  simple:	first
  |	simple word		{$$=tree2(ARGLIST, $1, $2);}
  |	simple redir		{$$=tree2(ARGLIST, $1, $2);}
/n/dump/2012/0330/sys/src/cmd/rc/syn.y:91,96 - syn.y:91,98
  word:	keyword			{lastword=1; $1->type=WORD;}
  |	comword
  |	word '^' word		{$$=tree2('^', $1, $3);}
+ nkword:	comword
+ |	word '^' word		{$$=tree2('^', $1, $3);}
  comword: '$' word		{$$=tree1('$', $2);}
  |	'$' word SUB words ')'	{$$=tree2(SUB, $2, $4);}
  |	'"' word		{$$=tree1('"', $2);}
/n/dump/2012/0330/sys/src/cmd/rc/syn.y:107,109 - syn.y:109,113
  |
  words:				{$$=(struct tree*)0;}
  |	words word		{$$=tree2(WORDS, $1, $2);}
+ nkwords:				{$$=(struct tree*)0;}
+ |	nkwords nkword		{$$=tree2(WORDS, $1, $2);}

Re: [9fans] rc: fn name @{block}

[Yaroslav]

> you've misunderstood the current grammar.  you have defined 2 functions
> name and '@' as {block}.  the binding, illustrated with parens is
>        fn (name @) {block}
> the production in the grammer is
>        FN words brace
> but since once production for words is words -> keyword, a keyword
> is a valid function name.

Then, how would you explain this:

term% fn x @{x=y}
term% whatis x
fn x {x=y}
term% fn 'x @'{x=y}
term% whatis 'x @'
fn 'x @' {x=y}

Re: [9fans] rc: fn name @{block}

[erik quanstrom]

> Then, how would you explain this:

it should be self-explanitory.

> term% fn x @{x=y}
> term% whatis x
> fn x {x=y}

creates to functions x and '@' definition {x=y}.

> term% fn 'x @'{x=y}
> term% whatis 'x @'
> fn 'x @' {x=y}

quoting disables any interpretation in rc; this isn't
the bourne shell.  what the parser sees is the following
tokens.
FN WORD '{' WORD '=' WORD '}'

 in this case 'x' for some x should be interpreted
differently than for shell input.  the *name* of the token
is 'x', not its value.  (such tokens typically have no value.)

it does not matter that the first WORD is
defined as 'x @'.

- erik

Re: [9fans] rc: fn name @{block}

[Yaroslav]

>> term% fn x @{x=y}
>> term% whatis x
>> fn x {x=y}
>
> creates to functions x and '@' definition {x=y}.

The question is why it discards @ here?

Re: [9fans] rc: fn name @{block}

[Anthony Sorace]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Mar 30, 2012, at 12:19 , Yaroslav wrote:

>>> term% fn x @{x=y}
>>> term% whatis x
>>> fn x {x=y}
>>
>> creates to functions x and '@' definition {x=y}.
>
> The question is why it discards @ here?

Erik's point is that rc isn't discarding it. You have a list. It sets x
equal to that function, then sets @ equal to that same function.

: iota; fn x @{x=y}
: iota; whatis x
fn x {x=y}
: iota; whatis '@'
fn @ {x=y}

When you quote the 'x @', that whole thing becomes one word.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 210 bytes --]

Re: [9fans] rc: fn name @{block}

[Yaroslav]

I see now. Thank you guys!

> Erik's point is that rc isn't discarding it. You have a list. It sets x
> equal to that function, then sets @ equal to that same function.
>
> : iota; fn x @{x=y}
> : iota; whatis x
> fn x {x=y}
> : iota; whatis '@'
> fn @ {x=y}

Re: [9fans] rc: fn name @{block}

[erik quanstrom]

On Fri Mar 30 07:43:57 EDT 2012, yarikos@gmail.com wrote:
> "fn name @{block}" doesn't cause block to run in a sub-shell, although
> it accepts the syntax.
> Is it someting should not be tried, or something shoud be fixed?

should be fixed.

- erik

[9fans] rc: fn name @{block}

[Yaroslav]

"fn name @{block}" doesn't cause block to run in a sub-shell, although
it accepts the syntax.
Is it someting should not be tried, or something shoud be fixed?