* [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909
@ 2021-07-09 7:48 Anthony Martin
2021-07-09 14:21 ` ori
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Anthony Martin @ 2021-07-09 7:48 UTC (permalink / raw)
To: 9front
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 7:48 [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 Anthony Martin @ 2021-07-09 14:21 ` ori 2021-07-09 14:37 ` Stanley Lieber 2021-08-27 15:07 ` ori 2 siblings, 0 replies; 13+ messages in thread From: ori @ 2021-07-09 14:21 UTC (permalink / raw) To: 9front 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 > You know, that's an interesting point. We can make the language more regular by simply removing the special case around function bodies, and making them behave the same as if, while, etc. It costs us this syntax: fn list of functions { ... } and requires us to be explicit: fn (list of functions) { ... } but on the other hand, things like fn foo echo hi fn foo @{echo hi} fn foo !bar fn foo !{bar} etc all work, just as they would in the body of any other statement.= AND it simplifies the code. It'd take some care moving forward with this, but it looks like there aren't very many places this is used; I've found one in our source tree, in ircrc: --- //.git/fs/object/2f8a59f4b5bfe028c022855acc19666d69eed909/tree//rc/bin/ircrc +++ /rc/bin/ircrc @@ -16,7 +16,7 @@ exit 'hang up' } -fn sigint sigterm { +fn (sigint sigterm) { if (! ~ $#netdir 0) echo QUIT : Leaving... > $netdir/data } --- //.git/fs/object/2f8a59f4b5bfe028c022855acc19666d69eed909/tree/sys/src/cmd/rc/syn.y +++ sys/src/cmd/rc/syn.y @@ -2,7 +2,7 @@ %term WORD REDIR DUP PIPE SUB %term SIMPLE ARGLIST WORDS BRACE PAREN PCMD PIPEFD /* not used in syntax */ /* operator priorities -- lowest first */ -%left IF WHILE FOR SWITCH ')' NOT +%left IF WHILE FOR SWITCH ')' NOT FN %left ANDAND OROR %left BANG SUBSHELL %left PIPE @@ -17,7 +17,7 @@ struct tree *tree; }; %type<tree> line paren brace body cmdsa cmdsan assign epilog redir -%type<tree> cmd simple first word comword keyword words comwords +%type<tree> cmd simple first word comword keyword words %type<tree> NOT FOR IN WHILE IF TWIDDLE BANG SUBSHELL SWITCH FN %type<tree> WORD REDIR DUP PIPE %% @@ -68,10 +68,7 @@ | assign cmd %prec BANG {$$=mung3($1, $1->child[0], $1->child[1], $2);} | BANG cmd {$$=mung1($1, $2);} | SUBSHELL cmd {$$=mung1($1, $2);} -| FN comwords brace {$$=tree2(FN, $2, $3);} -| FN comwords SUBSHELL brace - {$$=tree2(FN, $2, mung1($3, $4));} -| FN comwords {$$=tree1(FN, $2);} +| FN word cmd {$$=tree2(FN, $2, $3);} simple: first | simple word {$$=tree2(ARGLIST, $1, $2);} | simple redir {$$=tree2(ARGLIST, $1, $2);} @@ -92,5 +89,3 @@ keyword: FOR|IN|WHILE|IF|NOT|TWIDDLE|BANG|SUBSHELL|SWITCH|FN words: {$$=(struct tree*)0;} | words word {$$=tree2(WORDS, $1, $2);} -comwords: {$$=(struct tree*)0;} -| comwords comword {$$=tree2(WORDS, $1, $2);} ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 7:48 [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 Anthony Martin 2021-07-09 14:21 ` ori @ 2021-07-09 14:37 ` Stanley Lieber 2021-07-09 14:56 ` ori 2021-07-09 15:01 ` ori 2021-08-27 15:07 ` ori 2 siblings, 2 replies; 13+ messages in thread From: Stanley Lieber @ 2021-07-09 14:37 UTC (permalink / raw) To: 9front 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? (the mailing list itself relies on she'll scripts.) sl ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 14:37 ` Stanley Lieber @ 2021-07-09 14:56 ` ori 2021-07-09 15:01 ` ori 1 sibling, 0 replies; 13+ messages in thread From: ori @ 2021-07-09 14:56 UTC (permalink / raw) To: 9front Quoth Stanley Lieber <sl@stanleylieber.com>: > if we're introducing breaking changes to important programs like the shell, can we please at least post a warning on the mailing list? This change doesn't break anything -- any previously valid scripts remain valid. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 14:37 ` Stanley Lieber 2021-07-09 14:56 ` ori @ 2021-07-09 15:01 ` ori 2021-07-09 15:10 ` Stanley Lieber 1 sibling, 1 reply; 13+ messages in thread From: ori @ 2021-07-09 15:01 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 15:01 ` ori @ 2021-07-09 15:10 ` Stanley Lieber 2021-07-09 19:43 ` hiro 0 siblings, 1 reply; 13+ messages in thread From: Stanley Lieber @ 2021-07-09 15:10 UTC (permalink / raw) To: 9front On July 9, 2021 11:01:19 AM EDT, ori@eigenstate.org wrote: >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. > > thanks. changes to rc are tricky since of all things we expect it to behave consistently from day to day. I do think I misunderstood the change itself. I've been running sysupdate from cron and piping the output to an e-mail to myself -- the commit messages as printed by sysupdate are truncated. sl ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 15:10 ` Stanley Lieber @ 2021-07-09 19:43 ` hiro 2021-07-09 20:44 ` hiro 0 siblings, 1 reply; 13+ messages in thread From: hiro @ 2021-07-09 19:43 UTC (permalink / raw) To: 9front the examples are all weird. i still do not understand what this allows you to do. On 7/9/21, Stanley Lieber <sl@stanleylieber.com> wrote: > On July 9, 2021 11:01:19 AM EDT, ori@eigenstate.org wrote: >>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. >> >> > > thanks. changes to rc are tricky since of all things we expect it to behave > consistently from day to day. I do think I misunderstood the change itself. > I've been running sysupdate from cron and piping the output to an e-mail to > myself -- the commit messages as printed by sysupdate are truncated. > > sl > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 19:43 ` hiro @ 2021-07-09 20:44 ` hiro 2021-07-09 20:50 ` Stanley Lieber 0 siblings, 1 reply; 13+ messages in thread From: hiro @ 2021-07-09 20:44 UTC (permalink / raw) To: 9front i finally found a workable example, but i had to troll the irc logs to find it 23:36:05 ori → ok, rc updated - now if you need early exits in functions, 'fn foo @{...; exit; ...} On 7/9/21, hiro <23hiro@gmail.com> wrote: > the examples are all weird. i still do not understand what this allows > you to do. > > On 7/9/21, Stanley Lieber <sl@stanleylieber.com> wrote: >> On July 9, 2021 11:01:19 AM EDT, ori@eigenstate.org wrote: >>>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. >>> >>> >> >> thanks. changes to rc are tricky since of all things we expect it to >> behave >> consistently from day to day. I do think I misunderstood the change >> itself. >> I've been running sysupdate from cron and piping the output to an e-mail >> to >> myself -- the commit messages as printed by sysupdate are truncated. >> >> sl >> > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 20:44 ` hiro @ 2021-07-09 20:50 ` Stanley Lieber 2021-07-10 7:25 ` hiro 0 siblings, 1 reply; 13+ messages in thread From: Stanley Lieber @ 2021-07-09 20:50 UTC (permalink / raw) To: 9front On July 9, 2021 4:44:19 PM EDT, hiro <23hiro@gmail.com> wrote: >i finally found a workable example, but i had to troll the irc logs to find it > >23:36:05 ori → ok, rc updated - now if you need early exits in >functions, 'fn foo @{...; exit; ...} > > >On 7/9/21, hiro <23hiro@gmail.com> wrote: >> the examples are all weird. i still do not understand what this allows >> you to do. >> >> On 7/9/21, Stanley Lieber <sl@stanleylieber.com> wrote: >>> On July 9, 2021 11:01:19 AM EDT, ori@eigenstate.org wrote: >>>>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. >>>> >>>> >>> >>> thanks. changes to rc are tricky since of all things we expect it to >>> behave >>> consistently from day to day. I do think I misunderstood the change >>> itself. >>> I've been running sysupdate from cron and piping the output to an e-mail >>> to >>> myself -- the commit messages as printed by sysupdate are truncated. >>> >>> sl >>> >> > wait, this will exit only the subshell and not the parent? that's useful for sure. sl ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 20:50 ` Stanley Lieber @ 2021-07-10 7:25 ` hiro 2021-07-10 14:16 ` Stanley Lieber 0 siblings, 1 reply; 13+ messages in thread From: hiro @ 2021-07-10 7:25 UTC (permalink / raw) To: 9front that is how every subshell works, yes. the change regards delcaring a function in a way that it will thereafter always become a subshell, regardless how it is run. On 7/9/21, Stanley Lieber <sl@stanleylieber.com> wrote: > On July 9, 2021 4:44:19 PM EDT, hiro <23hiro@gmail.com> wrote: >>i finally found a workable example, but i had to troll the irc logs to find >> it >> >>23:36:05 ori → ok, rc updated - now if you need early exits in >>functions, 'fn foo @{...; exit; ...} >> >> >>On 7/9/21, hiro <23hiro@gmail.com> wrote: >>> the examples are all weird. i still do not understand what this allows >>> you to do. >>> >>> On 7/9/21, Stanley Lieber <sl@stanleylieber.com> wrote: >>>> On July 9, 2021 11:01:19 AM EDT, ori@eigenstate.org wrote: >>>>>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. >>>>> >>>>> >>>> >>>> thanks. changes to rc are tricky since of all things we expect it to >>>> behave >>>> consistently from day to day. I do think I misunderstood the change >>>> itself. >>>> I've been running sysupdate from cron and piping the output to an >>>> e-mail >>>> to >>>> myself -- the commit messages as printed by sysupdate are truncated. >>>> >>>> sl >>>> >>> >> > > wait, this will exit only the subshell and not the parent? that's useful for > sure. > > sl > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-10 7:25 ` hiro @ 2021-07-10 14:16 ` Stanley Lieber 0 siblings, 0 replies; 13+ messages in thread From: Stanley Lieber @ 2021-07-10 14:16 UTC (permalink / raw) To: 9front On July 10, 2021 3:25:48 AM EDT, hiro <23hiro@gmail.com> wrote: >that is how every subshell works, yes. > >the change regards delcaring a function in a way that it will >thereafter always become a subshell, regardless how it is run. > >On 7/9/21, Stanley Lieber <sl@stanleylieber.com> wrote: >> On July 9, 2021 4:44:19 PM EDT, hiro <23hiro@gmail.com> wrote: >>>i finally found a workable example, but i had to troll the irc logs to find >>> it >>> >>>23:36:05 ori → ok, rc updated - now if you need early exits in >>>functions, 'fn foo @{...; exit; ...} >>> >>> >>>On 7/9/21, hiro <23hiro@gmail.com> wrote: >>>> the examples are all weird. i still do not understand what this allows >>>> you to do. >>>> >>>> On 7/9/21, Stanley Lieber <sl@stanleylieber.com> wrote: >>>>> On July 9, 2021 11:01:19 AM EDT, ori@eigenstate.org wrote: >>>>>>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. >>>>>> >>>>>> >>>>> >>>>> thanks. changes to rc are tricky since of all things we expect it to >>>>> behave >>>>> consistently from day to day. I do think I misunderstood the change >>>>> itself. >>>>> I've been running sysupdate from cron and piping the output to an >>>>> e-mail >>>>> to >>>>> myself -- the commit messages as printed by sysupdate are truncated. >>>>> >>>>> sl >>>>> >>>> >>> >> >> wait, this will exit only the subshell and not the parent? that's useful for >> sure. >> >> sl >> > maybe we can get tom duff to update the rc paper to reflect our changes. sl ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-07-09 7:48 [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 Anthony Martin 2021-07-09 14:21 ` ori 2021-07-09 14:37 ` Stanley Lieber @ 2021-08-27 15:07 ` ori 2021-09-01 19:16 ` Noam Preil 2 siblings, 1 reply; 13+ messages in thread From: ori @ 2021-08-27 15:07 UTC (permalink / raw) To: 9front 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. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 2021-08-27 15:07 ` ori @ 2021-09-01 19:16 ` Noam Preil 0 siblings, 0 replies; 13+ messages in thread From: Noam Preil @ 2021-09-01 19:16 UTC (permalink / raw) To: 9front Given that fn foo{@{}} already works I think this patch is unnecessary even without getting into whether function coloring is a good idea. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-09-01 19:24 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-09 7:48 [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909 Anthony Martin 2021-07-09 14:21 ` ori 2021-07-09 14:37 ` Stanley Lieber 2021-07-09 14:56 ` ori 2021-07-09 15:01 ` ori 2021-07-09 15:10 ` Stanley Lieber 2021-07-09 19:43 ` hiro 2021-07-09 20:44 ` hiro 2021-07-09 20:50 ` Stanley Lieber 2021-07-10 7:25 ` hiro 2021-07-10 14:16 ` Stanley Lieber 2021-08-27 15:07 ` ori 2021-09-01 19:16 ` Noam Preil
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).