unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Magali Lemes <magalilemes00@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: [Outreachy] Use of impure functional programming and use of vlists
Date: Wed, 03 Mar 2021 15:00:27 +0100	[thread overview]
Message-ID: <87a6rks5fo.fsf@gnu.org> (raw)
In-Reply-To: <b20f3d5b-f4bb-a204-f430-7bcdfb5c5f1c@gmail.com> (Magali Lemes's message of "Sat, 27 Feb 2021 00:10:05 -0300")

Hi Magali,

Magali Lemes <magalilemes00@gmail.com> skribis:

> As my Outreachy internship approaches an end, I'd like to know which
> of the following options is better for walking and displaying the Git 
> commit history:
> 1) having a list and then using for-each it to display the commit
> information;
> 2) display the list while building it.

In addition to Arun’s suggestion, an option would be to achieve #2 while
keeping a functional approach; this can be done using SRFI-41 “streams”.

Streams are lazy lists, meaning that the elements of a stream are
computed on demand.  If you do:

  (use-modules (srfi srfi-41))

  (stream-for-each (lambda (n)
                     (pk (car (gettimeofday)) n))
                   (stream-cons 1
                                (stream-cons (begin (sleep 2) 2)
                                             stream-null)))

You’ll see that the first element is printed before we sleep for two
seconds.

I don’t know if this could work in your case; the Guile-Git API is eager
(as opposed to lazy), so maybe it’s not directly applicable.

> Another question is, could vlists be used? Since it would be fast to
> have the commits in a hash table implemented with vlists, we could use 
> 'vlist-for-each' to display the commits. I haven't seen vlist-for-each
> being used anywhere in Guix, so I wondered if there's a special reason 
> for it not being used, or if it hasn't really been necessary at all
> thus far.

Vlists are a sort of immutable data structures for vectors; for a
regular list, the cost of random access is linear in the size of the
list, whereas for vlists random access is “typically” constant-time,
almost like a vector.

The graph of commits is usually traversed linearly, so the complexity of
random access doesn’t matter much.  Likewise, in Guix proper, there are
probably few or no occasions where we need vector-like structures, which
is why vlists are not used.

HTH!

Ludo’.


  parent reply	other threads:[~2021-03-03 14:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-27  3:10 [Outreachy] Use of impure functional programming and use of vlists Magali Lemes
2021-02-27 12:36 ` Arun Isaac
2021-03-03 14:00 ` Ludovic Courtès [this message]
2021-03-05  0:06 ` zimoun

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=87a6rks5fo.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=magalilemes00@gmail.com \
    /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).