Output an alist from a function

Output an alist from a function

[Heime]

I have an alist composed of keys and associated directory paths, and want 
to output an alist made of the same keys with values being a validation flag.
Perhaps the problem is the call to mapcar.  In the case of the hash table I have
to call output-table after the maphash.

(defun dirpath-validation (input-table-or-alist)
  "Test validity of directory path for each key."

  (cond

      ((hash-table-p input-table-or-alist)

      ;; Make hash-table for output
      (let ( (output-table (make-hash-table :test 'equal)) )
        (maphash (lambda (key dirpath)
                   (puthash key (not (file-directory-p dirpath)) output-table))
                 input-table-or-alist)
        output-table))

      (t
         (mapcar (lambda (entry)
              (let ( (key      (car entry))
                     (dirpath  (cdr entry)) )
                (cons key (not (file-directory-p dirpath)))) )
            input-table-or-alist)) ))

Re: Output an alist from a function

[tomas]

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

On Mon, Sep 23, 2024 at 09:42:38PM +0000, Heime wrote:
> 
> I have an alist composed of keys and associated directory paths, and want 
> to output an alist made of the same keys with values being a validation flag.
> Perhaps the problem is the call to mapcar.  In the case of the hash table I have
> to call output-table after the maphash.
> 
> (defun dirpath-validation (input-table-or-alist)
>   "Test validity of directory path for each key."
> 
>   (cond
> 
>       ((hash-table-p input-table-or-alist)
> 
>       ;; Make hash-table for output
>       (let ( (output-table (make-hash-table :test 'equal)) )
>         (maphash (lambda (key dirpath)
>                    (puthash key (not (file-directory-p dirpath)) output-table))
>                  input-table-or-alist)
>         output-table))
> 
>       (t
>          (mapcar (lambda (entry)
>               (let ( (key      (car entry))
>                      (dirpath  (cdr entry)) )
>                 (cons key (not (file-directory-p dirpath)))) )
>             input-table-or-alist)) ))

I've some difficulties figuring out what your question is.

Is it that you want to write a function which "does the same"
as output-table does, but for alist?

Then we don't know what output-table does, so we can only guess.

Assuming it writes its content into a buffer, each entry on one
line, key and value separated by space, then this might do as a
rough prototype:

  (insert
    (mapc
      (lambda (k v) (format "%s %s\n) k v)
      input-table-or-alist))

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Output an alist from a function

[Stephen Berman]

On Mon, 23 Sep 2024 21:42:38 +0000 Heime <heimeborgia@protonmail.com> wrote:

> I have an alist composed of keys and associated directory paths, and want
> to output an alist made of the same keys with values being a validation flag.
> Perhaps the problem is the call to mapcar.  In the case of the hash table I have
> to call output-table after the maphash.
>
> (defun dirpath-validation (input-table-or-alist)
>   "Test validity of directory path for each key."
>
>   (cond
>
>       ((hash-table-p input-table-or-alist)
>
>       ;; Make hash-table for output
>       (let ( (output-table (make-hash-table :test 'equal)) )
>         (maphash (lambda (key dirpath)
>                    (puthash key (not (file-directory-p dirpath)) output-table))
>                  input-table-or-alist)
>         output-table))
>
>       (t
>          (mapcar (lambda (entry)
>               (let ( (key      (car entry))
>                      (dirpath  (cdr entry)) )
>                 (cons key (not (file-directory-p dirpath)))) )
>             input-table-or-alist)) ))

I get this:

(dirpath-validation #s(hash-table data ("a" "/usr" "b" "file")))
==> #s(hash-table test equal data ("a" nil "b" t))

(dirpath-validation '(("a" . "/usr") ("b" . "file")))
==> (("a") ("b" . t))

What's the problem?

Steve Berman

Re: Output an alist from a function

[Heime]

On Wednesday, September 25th, 2024 at 3:04 AM, tomas@tuxteam.de <tomas@tuxteam.de> wrote:

> On Mon, Sep 23, 2024 at 09:42:38PM +0000, Heime wrote:
> 
> > I have an alist composed of keys and associated directory paths, and want
> > to output an alist made of the same keys with values being a validation flag.
> > Perhaps the problem is the call to mapcar. In the case of the hash table I have
> > to call output-table after the maphash.
> > 
> > (defun dirpath-validation (input-table-or-alist)
> > "Test validity of directory path for each key."
> > 
> > (cond
> > 
> > ((hash-table-p input-table-or-alist)
> > 
> > ;; Make hash-table for output
> > (let ( (output-table (make-hash-table :test 'equal)) )
> > (maphash (lambda (key dirpath)
> > (puthash key (not (file-directory-p dirpath)) output-table))
> > input-table-or-alist)
> > output-table))
> > 
> > (t
> > (mapcar (lambda (entry)
> > (let ( (key (car entry))
> > (dirpath (cdr entry)) )
> > (cons key (not (file-directory-p dirpath)))) )
> > input-table-or-alist)) ))
> 
> 
> I've some difficulties figuring out what your question is.
> 
> Is it that you want to write a function which "does the same"
> as output-table does, but for alist?


Precisely. The function for hash tables accepts a hash table as input
and outputs another hash table, where the keys correspond to directory
validation flags. I use maphash to iterate over the elements, and after
constructing the new table during the loop, I retrieve and return the
output-table after maphash completes.

Similarly, in the case of alists, the function takes an alist (where
each element is a key paired with a directory path) and returns a new
alist, where each key is associated with its respective directory
validation flag. This mirrors the behavior of the hash table
implementation but uses alists instead.

Currently, I am using mapcar to iterate over the alist and apply the
transformation via a lambda function. However, I am uncertain whether
simply invoking mapcar is enough to ensure the same structured output as
with hash tables.

With hash tables, maphash alone wasn’t sufficient - I needed to
explicitly construct and return an output hash table within the
function.  My question is whether the same principle applies for alists:
do I need to construct and store the output alist in a temporary
structure, and then explicitly return it, akin to how I do with
output-table in the hash table case ?

 
> Then we don't know what output-table does, so we can only guess.
> 
> Assuming it writes its content into a buffer, each entry on one
> line, key and value separated by space, then this might do as a
> rough prototype:
> 
> (insert
> (mapc
> (lambda (k v) (format "%s %s\n) k v)
> input-table-or-alist))
> 
> Cheers
> --
> t

Re: Output an alist from a function

[tomas]

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

[I have re-added the mailing list in the CC]

On Tue, Sep 24, 2024 at 09:28:24PM +0000, Heime wrote:
> On Wednesday, September 25th, 2024 at 3:04 AM, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> 

[...]

> > I've some difficulties figuring out what your question is.
> > 
> > Is it that you want to write a function which "does the same"
> > as output-table does, but for alist?
> 
> 
> Precisely. The function for hash tables accepts a hash table as input
> and outputs another hash table, where the keys correspond to directory
> validation flags. I use maphash to iterate over the elements, and after
> constructing the new table during the loop, I retrieve and return the
> output-table after maphash completes.
> 
> Similarly, in the case of alists, the function takes an alist (where
> each element is a key paired with a directory path) and returns a new
> alist, where each key is associated with its respective directory
> validation flag. This mirrors the behavior of the hash table
> implementation but uses alists instead.
> 
> Currently, I am using mapcar to iterate over the alist and apply the
> transformation via a lambda function. However, I am uncertain whether
> simply invoking mapcar is enough to ensure the same structured output as
> with hash tables.

> With hash tables, maphash alone wasn’t sufficient - I needed to
> explicitly construct and return an output hash table within the
> function.  My question is whether the same principle applies for alists:
> do I need to construct and store the output alist in a temporary
> structure, and then explicitly return it, akin to how I do with
> output-table in the hash table case ?

I'd, (once again) refer you to the corresponding function documentations:
Mapcar collects the results of the function calls into a new list (if
that function returns pairs, as yours does, you end up with an alist).

Maphash "just" iterates over the key-value pairs. The naming is a bit
inconsistent, yes.

BTW: there is a function which "just" iterates over a list, "mapc". You
see it in the code snippet I gave you. You use that one when you'd throw
away the resulting list of "mapcar".

I'd recommend to read more docs and to *make little experiments* (i.e.
small programs of one, two or three lines) to check your understanding
of what you have read.

I see you stumbling time and again over very basic things, and you'd have
far less busywork if you had those basic things at your disposal.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Output an alist from a function

[Heime]

Sent with Proton Mail secure email.

On Wednesday, September 25th, 2024 at 4:39 PM, tomas@tuxteam.de <tomas@tuxteam.de> wrote:

> [I have re-added the mailing list in the CC]
> 
> On Tue, Sep 24, 2024 at 09:28:24PM +0000, Heime wrote:
> 
> > On Wednesday, September 25th, 2024 at 3:04 AM, tomas@tuxteam.de tomas@tuxteam.de wrote:
> 
> 
> [...]
> 
> > > I've some difficulties figuring out what your question is.
> > > 
> > > Is it that you want to write a function which "does the same"
> > > as output-table does, but for alist?
> > 
> > Precisely. The function for hash tables accepts a hash table as input
> > and outputs another hash table, where the keys correspond to directory
> > validation flags. I use maphash to iterate over the elements, and after
> > constructing the new table during the loop, I retrieve and return the
> > output-table after maphash completes.
> > 
> > Similarly, in the case of alists, the function takes an alist (where
> > each element is a key paired with a directory path) and returns a new
> > alist, where each key is associated with its respective directory
> > validation flag. This mirrors the behavior of the hash table
> > implementation but uses alists instead.
> > 
> > Currently, I am using mapcar to iterate over the alist and apply the
> > transformation via a lambda function. However, I am uncertain whether
> > simply invoking mapcar is enough to ensure the same structured output as
> > with hash tables.
> 
> > With hash tables, maphash alone wasn’t sufficient - I needed to
> > explicitly construct and return an output hash table within the
> > function. My question is whether the same principle applies for alists:
> > do I need to construct and store the output alist in a temporary
> > structure, and then explicitly return it, akin to how I do with
> > output-table in the hash table case ?
> 
> 
> I'd, (once again) refer you to the corresponding function documentations:
> Mapcar collects the results of the function calls into a new list (if
> that function returns pairs, as yours does, you end up with an alist).
> 
> Maphash "just" iterates over the key-value pairs. The naming is a bit
> inconsistent, yes.

Recognize the flaws in this school of thought. While it is acknowledged
that inconsistencies exist, the proposed solution is always to read more
documentation and conduct small experiments to figure things out
independently. This approach is highly inefficient, as it fails to
address the root inconsistencies. If these inconsistencies remain
unresolved, external assistance becomes far more critical than merely
persisting with an incoherent system in the hope of some sudden
breakthrough.

> BTW: there is a function which "just" iterates over a list, "mapc". You
> see it in the code snippet I gave you. You use that one when you'd throw
> away the resulting list of "mapcar".
> 
> I'd recommend to read more docs and to make little experiments (i.e.
> small programs of one, two or three lines) to check your understanding
> of what you have read.
> 
> I see you stumbling time and again over very basic things, and you'd have
> far less busywork if you had those basic things at your disposal.
> 
> Cheers
> --
> t

Re: Output an alist from a function

[tomas]

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

On Wed, Sep 25, 2024 at 08:30:30PM +0000, Heime wrote:

[...]

> > Maphash "just" iterates over the key-value pairs. The naming is a bit
> > inconsistent, yes.
> 
> Recognize the flaws in this school of thought. While it is acknowledged
> that inconsistencies exist, the proposed solution is always to read more
> documentation and conduct small experiments to figure things out
> independently. This approach is highly inefficient [...]

This may apply when you're designing a new system. On an old system,
with nearly 40 years of history and lots of dependencies, there are
limits to how quickly you can change things without breaking programs
and users you haven't ever heard of.

You'll always have inconsistencies. Removing them is an ongoing process
which happens very carefully, and is in a steady state wrt introducing
new ones.

At this stage, the evolution resembles that of human languages (which
do have their sets of inconsistencies).

You can try to build your own to get a feel of what's involved. It's
harder than it seems.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Output an alist from a function

[Heime]

Sent with Proton Mail secure email.

On Thursday, September 26th, 2024 at 4:43 PM, tomas@tuxteam.de <tomas@tuxteam.de> wrote:

> On Wed, Sep 25, 2024 at 08:30:30PM +0000, Heime wrote:
> 
> [...]
> 
> > > Maphash "just" iterates over the key-value pairs. The naming is a bit
> > > inconsistent, yes.
> > 
> > Recognize the flaws in this school of thought. While it is acknowledged
> > that inconsistencies exist, the proposed solution is always to read more
> > documentation and conduct small experiments to figure things out
> > independently. This approach is highly inefficient [...]
> 
> 
> This may apply when you're designing a new system. On an old system,
> with nearly 40 years of history and lots of dependencies, there are
> limits to how quickly you can change things without breaking programs
> and users you haven't ever heard of.

For what I am doing, the problem is not acute and with your suggestion 
towards mapc, I made

       ;; Initialize an empty alist to hold output
       (let ( (output-alist '()) )
         ;; `mapc' iterates over an alist in a manner similar to how
         ;; `maphash' processes a hash table.
         (mapc (lambda (entry)
                 (let ( (waypt    (car entry))
                        (dir-path (cdr entry)) )
                   ;; Push the result to the front of the output alist
                   (push (cons waypt (not (file-directory-p dir-path)))
                         output-alist)))
               fpln)
         ;; Reverse the list to maintain the original order
         (reverse output-alist)))
 
> You'll always have inconsistencies. Removing them is an ongoing process
> which happens very carefully, and is in a steady state wrt introducing
> new ones.
> 
> At this stage, the evolution resembles that of human languages (which
> do have their sets of inconsistencies).

It is as Guy Steele used to describe a programming language.  I attended one
of his speeches. 
 
> You can try to build your own to get a feel of what's involved. It's
> harder than it seems.
> 
> Cheers
> --
> t

Re: Output an alist from a function

[tomas]

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

On Thu, Sep 26, 2024 at 08:23:02AM +0000, Heime wrote:
> Sent with Proton Mail secure email.
> 
> On Thursday, September 26th, 2024 at 4:43 PM, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> 
> > On Wed, Sep 25, 2024 at 08:30:30PM +0000, Heime wrote:

[...]

> For what I am doing, the problem is not acute and with your suggestion 
> towards mapc, I made
> 
>        ;; Initialize an empty alist to hold output
>        (let ( (output-alist '()) )
>          ;; `mapc' iterates over an alist in a manner similar to how
>          ;; `maphash' processes a hash table.
>          (mapc (lambda (entry)
>                  (let ( (waypt    (car entry))
>                         (dir-path (cdr entry)) )
>                    ;; Push the result to the front of the output alist
>                    (push (cons waypt (not (file-directory-p dir-path)))
>                          output-alist)))
>                fpln)
>          ;; Reverse the list to maintain the original order
>          (reverse output-alist)))

If all you need is to print a formatted rendering of the alist/hash,
perhaps you can skip the generation of an intermediate data structure?

(I don't know what your greater plan is, so perhaps that musing is
irrelevant)

> > You'll always have inconsistencies. Removing them is an ongoing process
> > which happens very carefully, and is in a steady state wrt introducing
> > new ones.
> > 
> > At this stage, the evolution resembles that of human languages (which
> > do have their sets of inconsistencies).
> 
> It is as Guy Steele used to describe a programming language.  I attended one
> of his speeches. 

After all, programming languages are also human languages, with all their
cultural traits, tribalities, identity facets, yadda, yadda. Had I the
choice today, I'd study programming language anthropology.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Output an alist from a function

[Heime]

Sent with Proton Mail secure email.

On Thursday, September 26th, 2024 at 9:01 PM, tomas@tuxteam.de <tomas@tuxteam.de> wrote:

> On Thu, Sep 26, 2024 at 08:23:02AM +0000, Heime wrote:
> 
> > Sent with Proton Mail secure email.
> > 
> > On Thursday, September 26th, 2024 at 4:43 PM, tomas@tuxteam.de tomas@tuxteam.de wrote:
> > 
> > > On Wed, Sep 25, 2024 at 08:30:30PM +0000, Heime wrote:
> 
> 
> [...]
> 
> > For what I am doing, the problem is not acute and with your suggestion
> > towards mapc, I made
> > 
> > ;; Initialize an empty alist to hold output
> > (let ( (output-alist '()) )
> > ;; `mapc' iterates over an alist in a manner similar to how ;;` maphash' processes a hash table.
> > (mapc (lambda (entry)
> > (let ( (waypt (car entry))
> > (dir-path (cdr entry)) )
> > ;; Push the result to the front of the output alist
> > (push (cons waypt (not (file-directory-p dir-path)))
> > output-alist)))
> > fpln)
> > ;; Reverse the list to maintain the original order
> > (reverse output-alist)))
> 
> 
> If all you need is to print a formatted rendering of the alist/hash,
> perhaps you can skip the generation of an intermediate data structure?
> 
> (I don't know what your greater plan is, so perhaps that musing is
> irrelevant)

My goal is to explore different approaches to deepen my understanding of 
various macros and their behavior.  Implementing multiple versions of the same 
functionality to serve as valuable exercises in grasping the nuances of these 
constructs. While generating an intermediate data structure may not be strictly 
necessary for outputting a formatted rendering, this experimentation should  
solidify my understanding of how these tools can be applied in different 
contexts.
 
> > > You'll always have inconsistencies. Removing them is an ongoing process
> > > which happens very carefully, and is in a steady state wrt introducing
> > > new ones.
> > > 
> > > At this stage, the evolution resembles that of human languages (which
> > > do have their sets of inconsistencies).
> > 
> > It is as Guy Steele used to describe a programming language. I attended one
> > of his speeches.
> 
> 
> After all, programming languages are also human languages, with all their
> cultural traits, tribalities, identity facets, yadda, yadda. Had I the
> choice today, I'd study programming language anthropology.

Have worked with Leslie Lamport (Turing Award Winner 2013 by the ACM) and he 
has shown how the Temporal Logic of Actions is superior to human languages, 
and even to mathematics itself.
 
> Cheers
> --
> t