Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909

[ori@eigenstate.org]

Quoth Stanley Lieber <sl@stanleylieber.com>:
> On July 9, 2021 3:48:39 AM EDT, Anthony Martin <ality@pbrane.org> wrote:
> >> rc: add subshell-function syntax
> >>
> >> fn foo @{bar} is now equivalent to
> >> fn foo {@{bar}}. As a side effect,
> >> this disallows creating functions
> >> named after keywords without first
> >> quoting them.
> >
> >Respectfully, this is just wrong. @ is a
> >unary operator. Repurposing it to define
> >a new special kind of function is a bit
> >much.
> >
> >What does this buy you over being explicit
> >at the call site?
> >
> >	fn foo { bar }
> >
> >	@foo
> >
> >One color of function is enough. What's
> >next?
> >
> >	fn foo !{ bar }
> >
> >to mean that foo always negates the exit
> >status of its body?
> >
> >The new quoting requirement for functions
> >named after keywords seems fine, on the
> >other hand. But is it worth the backwards
> >incompatibility?
> >
> >Thanks,
> >  Anthony
> >
> 
> if we're introducing breaking changes to important programs like the shell, can we please at least post a warning on the mailing list?

(caveat -- it's compatible unless you
happen to be using functions named '@',
'`', etc -- which, again, you
can't use without quoting.)

I don't think most people even realize
that it's possible to name an rc function:

	'@{this is a valid} function name!'

Either way, noted -- I'll post next time.