From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id EA70A388B034 for ; Tue, 9 Jun 2020 22:59:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EA70A388B034 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [172.16.0.95] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 660A31E791; Tue, 9 Jun 2020 18:59:50 -0400 (EDT) Subject: Re: [RFAv6 1/3] default-args: allow to define default arguments for aliases To: Philippe Waroquiers , gdb-patches@sourceware.org References: <20200516171947.10507-1-philippe.waroquiers@skynet.be> <20200516171947.10507-2-philippe.waroquiers@skynet.be> <9419d28e-994d-ec6a-c202-098937c0198f@simark.ca> <03ebfe32742f6c66d168cbc7bbc18073a03d8e54.camel@skynet.be> From: Simon Marchi Message-ID: <540c4499-a74c-85c2-6fea-473088ce3144@simark.ca> Date: Tue, 9 Jun 2020 18:59:50 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <03ebfe32742f6c66d168cbc7bbc18073a03d8e54.camel@skynet.be> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 22:59:53 -0000 On 2020-06-09 3:49 p.m., Philippe Waroquiers wrote: > Hello Simon, > > On Mon, 2020-06-08 at 17:28 -0400, Simon Marchi wrote: >> I don't remember if we talked about this earlier... but is this >> the expected behavior when using an alias to define another alias? > > This point was not discussed but is the consequence of GDB > resolving an alias to point at the (end/final) command it is > aliasing, and e.g. not mplementing an alias as a kind of textual > replacement. > When asking the list of aliases, it similarly shows the 'final' > command it is aliasing, and not the alias that was used > in the definition. > > (gdb) alias aaa = echo bonjour > (gdb) alias bbb = aaa coucou > (gdb) help aliases > User-defined aliases of other commands. > > List of commands: > > aaa -- Print a constant string. Give string as argument. > alias aaa = echo bonjour > bbb -- Print a constant string. Give string as argument. > alias bbb = echo coucou > > We might explicit this behaviour in the user manual. > (it might be possible to re-implement aliases as textual > replacement but that is a major rework, e.g. the > chain of aliases of a command has to be replaced > by something else, the aliased_command pointer is to point > at another chain of aliases, that must be evaluated "dynamically" > when executing the command, rather than resolved at definition time. I understand that this is because of the current implementation, but I really think that the behavior is unexpected from the point of view of the user. If default arguments don't add up when defining an alias based on another alias, then I'd suggest preventing the user from creating aliases based on other aliases. The rationale being that there is no point in doing: (gdb) alias aaa = print abc (gdb) alias bbb = aaa def over (gdb) alias aaa = print abc (gdb) alias bbb = print def And the former would just cause confusion with the current behavior (even if documented in the manual). Plus, if we allow the former, we will be stuck with this behavior, we won't be able to change it in the future if we want to implement the behavior where the default arguments accumulate. I have to admit that I didn't dig much in the implementation, but this is how I would see it. Right now, when you define `bbb`, bbb's cmd_list_element->cmd_pointer points to print's cmd_list_element. Would it be hard to make it point to aaa's cmd_list_element instead? This way, when we look up command `bbb`, we could resolve the aliases recursively (or iteratively) and just build up the default args string as each alias level is resolved. If we take the example from above, when executing command `bbb`, we would end up with default args "abc def". I presume it's doable but not a simple change, so that's why I suggest for now to just prevent defining aliases based on aliases, so we can keep the door open to implementing it later. > Note that GDB and a shell are already very different beasts > on many aspects e.g. : > (gdb) set $xxx = "coucou" > (gdb) echo $xxx > $xxx(gdb) p $xxx > $1 = "coucou" > (gdb) Of course! But it doesn't prevent us from stealing good ideas from the shell :). Simon