Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909

[ori@eigenstate.org]

Quoth Anthony Martin <ality@pbrane.org>:
> > 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
> 

After a bunch of time/thought, trying it
out, and realizing I'm not really getting
much mileage out if it:

I'm going to revert this some time next week.