From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@labs.coraid.com>
Date: Fri, 30 Mar 2012 12:01:51 -0400
To: 9fans@9fans.net
Message-ID: <0f0fc69bdeaa05f0bdac2954d8d3a1db@coraid.com>
In-Reply-To: <CAG3N4d_5f97O85mwGnrawwiGQAPN+K6CTQ0vbpk2EexkpbH0qg@mail.gmail.c>
References: <CAG3N4d81u5p-WVz5aXnjGE8ON5BMd-AEr0xRMjP+Ug4G9Db=UA@mail.gmail.c>
	<f78242cdae3fa424364038ed0d7c7dd0@coraid.com>
	<CAG3N4d_5f97O85mwGnrawwiGQAPN+K6CTQ0vbpk2EexkpbH0qg@mail.gmail.c>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] rc: fn name @{block}
Topicbox-Message-UUID: 72abd90a-ead7-11e9-9d60-3106f5b1d025

> 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