9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] Re: commit 2f8a59f4b5bfe028c022855acc19666d69eed909
@ 2021-07-09  7:48 Anthony Martin
  2021-07-09 14:21 ` ori
  2021-07-09 14:37 ` Stanley Lieber
  0 siblings, 2 replies; 11+ 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] 11+ 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
  1 sibling, 0 replies; 11+ 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] 11+ 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
  1 sibling, 2 replies; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ 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; 11+ 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] 11+ messages in thread

end of thread, other threads:[~2021-07-11 10:15 UTC | newest]

Thread overview: 11+ 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

9front - general discussion about 9front

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/9front

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 9front 9front/ http://inbox.vuxu.org/9front \
		9front@9front.org
	public-inbox-index 9front

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.9front


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git