From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id iGUtEthYnF92ewAA0tVLHw (envelope-from ) for ; Fri, 30 Oct 2020 18:18:00 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id uNLzDdhYnF+AWgAAB5/wlQ (envelope-from ) for ; Fri, 30 Oct 2020 18:18:00 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 05EA394042E for ; Fri, 30 Oct 2020 18:18:00 +0000 (UTC) Received: from localhost ([::1]:35866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYYyN-000829-03 for larch@yhetil.org; Fri, 30 Oct 2020 14:17:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46932) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYYy9-00081t-6B for guix-devel@gnu.org; Fri, 30 Oct 2020 14:17:45 -0400 Received: from mail-ej1-x630.google.com ([2a00:1450:4864:20::630]:46158) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYYy6-0006Hu-ND for guix-devel@gnu.org; Fri, 30 Oct 2020 14:17:44 -0400 Received: by mail-ej1-x630.google.com with SMTP id t25so9791101ejd.13 for ; Fri, 30 Oct 2020 11:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=L43terAOEg2lZf4SRTK+yjK657fzMuxJFehrmIpzb+U=; b=V0j7EnInqLkySDDgWtWfOMND5DNijvPgoAGu6rEg7z/DxpMz8DIj/SudhweER5IW9H 9dO/OcBJADoUYRVOhIk5vqby3T2HsfPK8BB1g+uE9SuPgDSvy02IgpcqIHhMn3qV+QJp N7miPKAWiQPCbWYQALhCQGOT4PUPP/F2rgTwgoSdbrjl5n+vtFHLjtXDcpRX9gCU/Yt3 T4/Up4HmVfd7rz7G2zBxEXw8Pe94ehMjHB6y684hI4gU/kv42G0CeBFW9aTF57CVOU0U ilogj+AupZDo6WPmsg650NxDJn+eFZrTpBB0rydDUeuUa65i3Zs9s1c63C/2utf48XhZ h8wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=L43terAOEg2lZf4SRTK+yjK657fzMuxJFehrmIpzb+U=; b=iW5lnbLGo88ZTdwVO2GWQDvnY8yZOyv5BOU+TFOlpbJdJO0LdpVZrLU/JNVx8DFXwY qXtQp6Ubsq0MZVEhQg9LM7b0oREGf9hErSOz3l4MgcnGV7mv1Vuus+/LQCR7xdCR9PXt BDJpbxc0NnTftWOunk06ziUXo3mM5PMHvRw/d5kffWBQaxhsdzk2lx4EI6Il6Fpu0huQ 2msszM6a8YjAsAfNHdbt1BuoXSkJ8QLoPqNFBllYOBq41/M4IlYD4emzupY50aKjBjEO eL9J40NiW+4z+NMAxipS9PJSYS52OeYbq6ybuhKy5k30ThQORmxWI3SXezjhgkMAGZJl JynA== X-Gm-Message-State: AOAM531wNFrejoylFX9NopiEjv1yd12RIsGPc3FaMWfHsxxyaN6MJG6N QDWAGD/dJQbypIxK1XleTSwh/mNFe1sP2Q== X-Google-Smtp-Source: ABdhPJyqdayj8AwsblFcr+c8M8APssIepbpdDxuHecZo6FgKN7NW7gddQLmwi1aJkTM7drytDezZKQ== X-Received: by 2002:a17:906:1a0e:: with SMTP id i14mr3853339ejf.7.1604081859186; Fri, 30 Oct 2020 11:17:39 -0700 (PDT) Received: from ?IPv6:2a02:908:c71:ba60:7cb0:fd4b:2ad9:1d0e? ([2a02:908:c71:ba60:7cb0:fd4b:2ad9:1d0e]) by smtp.gmail.com with ESMTPSA id p3sm3354831edy.38.2020.10.30.11.17.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Oct 2020 11:17:38 -0700 (PDT) Subject: Re: A better way to access records. To: Brendan Tildesley , guix-devel References: <487cea17-061a-2cc9-6b3e-7b688114d158@brendan.scot> From: Taylan Kammer Message-ID: <2f300474-542c-f1de-7744-92618c74cee8@gmail.com> Date: Fri, 30 Oct 2020 19:17:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <487cea17-061a-2cc9-6b3e-7b688114d158@brendan.scot> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2a00:1450:4864:20::630; envelope-from=taylan.kammer@gmail.com; helo=mail-ej1-x630.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.253, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=V0j7EnIn; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: -1.71 X-TUID: lrH3JPfSyqHk On 30.10.2020 11:28, Brendan Tildesley wrote: > In the guix codebase, on many occasions there appear things like this: > > (match-lambda > (($ agetty tty term baud-rate auto-login > login-program login-pause? eight-bits? no-reset? remote? flow-control? > host no-issue? init-string no-clear? local-line extract-baud? > skip-login? no-newline? login-options chroot hangup? keep-baud? timeout > detect-case? wait-cr? no-hints? no-hostname? long-hostname? > erase-characters kill-characters chdir delay nice extra-options) > (list > .... > > Wouldn't be nice if we could just step inside a record type whenever we > pleased? > The above would be like this perhaps: > > (let-from-record-type >  (list ...)) > Usually in Scheme the concept of "lexical scope" is held in very high regard, which means that for every identifier that is being referenced in a piece of code, you should be able to see its verbatim definition or binding (with 'define' or 'let') in the text, with the exception of imports of course. This has various advantages, like being intuitive, making name clashes unlikely, making it easy for IDEs and other tools to find the definition of a binding, and so on. Of course, the disadvantage is the verbosity. Digression: This is also the crux of the debate on whether it's a good idea for a record definition syntax to implicitly bind procedures. For instance would it be a blessing or a curse if I could just say (define-record-type (make-rec foo bar) rec?) and automatically have rec-foo, set-rec-foo!, rec-bar and set-rec-bar! defined for me, even though none of those identifiers appear in the definition of the record type... End digression. As seen in your example, a record may have tons of fields. Binding them all automatically would IMO be quite bad in some cases. In the list we see very generic identifiers like 'term', 'host', 'timeout', 'chdir' and 'delay'. Binding these implicitly would be Very Bad(TM) because you might have been using them for something else and happen to forget that this record type contains them and as such the 'let-from-record-type' overrides your bindings. Worse yet: when the record gets more fields, your code might break because one of the new fields happens to be an identifier that you were using in your code! Consider the following. Let's say the does not yet have a field called 'chdir' and nobody has any idea that one day it will be added. I write the following code: (let-from-record my-agetty-config (let ((orig-dir (get-working-dir)) (tmpdir (make-tmp-dir)) (chdir tmpdir) (do-something-with-agetty-config) (chdir orig-dir))) One day, 'chdir' is added to the agetty-configuration record type... Well I assume you see the problem. :-) In code where the bindings to be taken from the record are listed explicitly, such a problem cannot occur. - Taylan