unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Taylan Kammer <taylan.kammer@gmail.com>
To: Brendan Tildesley <mail@brendan.scot>, guix-devel <guix-devel@gnu.org>
Subject: Re: A better way to access records.
Date: Fri, 30 Oct 2020 19:17:37 +0100	[thread overview]
Message-ID: <2f300474-542c-f1de-7744-92618c74cee8@gmail.com> (raw)
In-Reply-To: <487cea17-061a-2cc9-6b3e-7b688114d158@brendan.scot>

On 30.10.2020 11:28, Brendan Tildesley wrote:
> In the guix codebase, on many occasions there appear things like this:
>
> (match-lambda
>     (($ <agetty-configuration> 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 <agetty-configuration>
>   (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 <rec> (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 <agetty-configuration> 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


  parent reply	other threads:[~2020-10-30 18:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-30 10:28 A better way to access records Brendan Tildesley
2020-10-30 11:04 ` Bengt Richter
2020-10-30 18:17 ` Taylan Kammer [this message]
2020-10-31 22:01 ` Ludovic Courtès
2020-11-13 11:24   ` Brendan Tildesley
  -- strict thread matches above, loose matches on Subject: below --
2020-10-30 10:49 Leo Prikler
2020-10-30 10:59 ` Brendan Tildesley
2020-10-30 19:47   ` Danny Milosavljevic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2f300474-542c-f1de-7744-92618c74cee8@gmail.com \
    --to=taylan.kammer@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=mail@brendan.scot \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).