A better way to access records.

A better way to access records.

[Brendan Tildesley]

 From the little bit of SICP that I've done, I recall watching the 
lectures where
they put a mage hat on and talk about the power of names. One could 
perhaps say
the most powerful tool in a programming language is the ability to give
something a name and then refer to those names.

In guix/guile, record types are  list of names given to some data.
For example:

(define foo
   (package
    (name "bar")
    (version "1.0")
    ...)

Here we the names foo, name, version, that refer to things of interest. 
We can
call foo easily enough to get the record, but we cannot refer to name or
version so easily.  We instead have to use accessors like (package-name 
foo),
which requires us to write foo each time explicitly and have repeat package-
for each accessor.
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
       ....

Here we have given some names to things, abandoned those names, and once 
again
gone to the trouble of naming them again, in order, just for one local
environment. We'd have to do it again to make use of it elsewhere, and I 
assume
they would have to change if the record type it self needed to be updated.

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 ...))

"let-from-record-type" i just made up since i dont know what it should be
called.  Anyhow, it seems like we're stepping back a few centuries in 
computer
science by needing to jump through these hoops.

The list of symbols can be retreived with (record-type-fields
<agetty-configuration>), but I can't think of how one would write the above
syntax.

Opinions?

Re: A better way to access records.

[Leo Prikler]

Well, the "functional" way of accessing them all in one go would be to 
  (map (cute <> foo) (list package-name package-version package-...))
But I assume you want syntax like

(let-field record field exp*)
(let-fields record (field1 field2...) exp*)

analogous to (srfi srfi-9 gnu) set-field and set-fields, am I right?

Regards, Leo

Re: A better way to access records.

[Brendan Tildesley]

On 30/10/20 8:49 pm, Leo Prikler wrote:
> Well, the "functional" way of accessing them all in one go would be to
>    (map (cute <> foo) (list package-name package-version package-...))
> But I assume you want syntax like
>
> (let-field record field exp*)
> (let-fields record (field1 field2...) exp*)
No I didn't want to specify the fields at all, just have all of them 
automatically defined.
> analogous to (srfi srfi-9 gnu) set-field and set-fields, am I right?
>
> Regards, Leo
>

Re: A better way to access records.

[Bengt Richter]

Hi Brendan,

On +2020-10-30 21:28:38 +1100, Brendan Tildesley wrote:
> From the little bit of SICP that I've done, I recall watching the lectures
> where
> they put a mage hat on and talk about the power of names. One could perhaps
> say
> the most powerful tool in a programming language is the ability to give
> something a name and then refer to those names.
> 
> In guix/guile, record types are  list of names given to some data.
> For example:
> 
> (define foo
>   (package
>    (name "bar")
>    (version "1.0")
>    ...)
> 
> Here we the names foo, name, version, that refer to things of interest. We
> can
> call foo easily enough to get the record, but we cannot refer to name or
> version so easily.  We instead have to use accessors like (package-name
> foo),
> which requires us to write foo each time explicitly and have repeat package-
> for each accessor.
> 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
>       ....
> 
> Here we have given some names to things, abandoned those names, and once
> again
> gone to the trouble of naming them again, in order, just for one local
> environment. We'd have to do it again to make use of it elsewhere, and I
> assume
> they would have to change if the record type it self needed to be updated.
> 
> 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 ...))
> 
> "let-from-record-type" i just made up since i dont know what it should be
> called.  Anyhow, it seems like we're stepping back a few centuries in
> computer
> science by needing to jump through these hoops.
> 
> The list of symbols can be retreived with (record-type-fields
> <agetty-configuration>), but I can't think of how one would write the above
> syntax.
> 
> Opinions?
> 
> 
>

    info guile record

may be useful :)

-- 
Regards,
Bengt Richter

Re: A better way to access records.

[Taylan Kammer]

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

Re: A better way to access records.

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

Hi Brendan,

On Fri, 30 Oct 2020 21:59:59 +1100
Brendan Tildesley <mail@brendan.scot> wrote:

> No I didn't want to specify the fields at all, just have all of them 
> automatically defined.

I think that that is a bad idea for maintenance reasons.

This totally would hide variables from the enclosing context without you
being able to tell that it does so from the lexical context.

For example let's say you have:

(define-record <foo> size)

(let ((color 5))
  (with-record foo
    color))

And later on you update <foo> (but do not change the text of the with-record
usage at all), so in total you have:

(define-record <foo> size color)

(let ((color 5))
  (with-record foo
    color))

Now color is a different one!!

I don't even like unqualified imports for that reason: a change in a remote
place can affect what this module does without this module body referring
to it literally in the first place.

On the other hand, when directly specifying the fields

  (let ((color 5))
    (with-record (foo size)
      color))

I'm all for that.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: A better way to access records.

[Ludovic Courtès]

Hi,

Brendan Tildesley <mail@brendan.scot> skribis:

> 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
>       ....

This has officially been Bad Practice for a while.  Instead, the
recommended approach is to use ‘match-record’ from (guix records).
There are examples of that primarily in (gnu services …).

Does that help?

Thanks,
Ludo’.

Re: A better way to access records.

[Brendan Tildesley]

On 1/11/20 8:01 am, Ludovic Courtès wrote:
> Hi,
>
> Brendan Tildesley <mail@brendan.scot> skribis:
>
>> 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
>>        ....
> This has officially been Bad Practice for a while.  Instead, the
> recommended approach is to use ‘match-record’ from (guix records).
> There are examples of that primarily in (gnu services …).
>
> Does that help?
>
> Thanks,
> Ludo’.

I suppose It makes sense that one would want to be explicit about names 
in a source code file.

BTW, if that is the recommended way, would someone with an understanding 
of the records.scm code mind adding support for delayed & thunked fields 
in match-record? There is a TODO there. I wouldn't know how to do it.