IRC channel logs

2025-07-10.log

back to list of logs

<lechner>Hi, why does anyone use vectors, please, when arrays can have a single dimension?
<dthompson>using arrays when working with a single dimension just adds overhead
<dthompson>the multi-dimensionality and polymorphism of arrays can be cool but usually I just want a plain old vector.
<lechner>dthompson / Thanks! What is the polymorphism Guile arrays, please?
<lechner>of Guile arrays
<dthompson>the array api works on vector and array values
<lechner>thanks!
<lechner>Hi, to keep order I use keywords when procedures have a lot of parameters, but things aren't so rosy when they return nine values. Do association lists make APIs or should I go with hashes and vectors? The return values are generally structured and can have multiple levels. Thanks!
<lechner>make good APIs
<mwette>For nine I use alists. I think they are easier to work with (e.g., acons, and if you need to print for debugging).
<lechner>mwette / thanks! this is actually, in part, a cdata question. do you think this is a sensible, though incomplete, way to transform cdata objects into scheme values? https://bpa.st/5ZTQ
<lechner>struct to alist, array to plain list
<mwette>that is probably needed. you can look at the cdata-info accessors; maybe check out pretty-print-ctype ..
<mwette>ACTION afk
<mwette>the difference between the fields member and select member is that the select projects anonymous substruct members up, so select member of { int a; struct { int b;}} is (a . int) (b . int)
<ArneBab>sneek: later tell lechner: I find alists nicer to work with than hash maps, and they need less memory (but are slower). You could also check if you can replace some big alists records (define-record-type). Those are faster and can consume less memory (similar to vectors).
<sneek>Got it.
<dsmith>alists also have a read syntax
<Arsen>is that not regular list syntax?
<identity>sure, alists are just lists
<identity>i guess it is not ‘regular list’ syntax, but ‘dotted list’ syntax, tho
<mwette>sneek: later tell lechner, maybe something like this (w/ 2.02.2+): https://paste.debian.net/1385219/ (but obj => cdata-object, and add check for (cdata? cdata-object)
<sneek>Got it.
<lechner>Hi, is anyone wishing for a better 'pretty-print' for records?
<sneek>Welcome back lechner, you have 2 messages!
<sneek>lechner, ArneBab says: I find alists nicer to work with than hash maps, and they need less memory (but are slower). You could also check if you can replace some big alists records (define-record-type). Those are faster and can consume less memory (similar to vectors).
<sneek>lechner, mwette says: maybe something like this (w/ 2.02.2+): https://paste.debian.net/1385219/ (but obj => cdata-object, and add check for (cdata? cdata-object)
<lechner>sneek / later tell mwette / thanks! yeah, I thought about pointers, too. As for arrays, vectors seemed inconsistent with my choice of alists for structs. I am currently motivated to go complex on all, i.e. vectors for arrays and records for structs. Would you accept a patch that creates and ships parallel record definitions for CDATA structs?
<sneek>Will do.
<lechner>sneek / later tell ArneBab / my issue with alists is they mix data with structure. I decode bitmaps into symbol lists and am currently unclear whether records and vectors would draw that line more clearly
<sneek>Okay.
<lechner>sneek / later tell mwette / thanks for the fold-right! without typos it now looks like this: https://bpa.st/7SXA but I get "Wrong number of arguments to #<procedure lkup (sym)>" which I have never seen
<sneek>Got it.
<lechner>sneek / later ask mwette / why does cstruct-select return a procedure, please?
<sneek>Okay.
<mwette>lechner: I mentioned w/ 2.02.2+ I had to make a change to get the keys. The reason that it's a procedure is to allow optimization for accessing fields. Right now the implementation is alists but it should be possible to use hash table (and still keep the api the same). Here is the change: https://paste.debian.net/1385238/
<sneek>Welcome back mwette, you have 3 messages!
<sneek>mwette, lechner says: / thanks! yeah, I thought about pointers, too. As for arrays, vectors seemed inconsistent with my choice of alists for structs. I am currently motivated to go complex on all, i.e. vectors for arrays and records for structs. Would you accept a patch that creates and ships parallel record definitions for CDATA structs?
<sneek>mwette, lechner says: / thanks for the fold-right! without typos it now looks like this: https://bpa.st/7SXA but I get "Wrong number of arguments to #<procedure lkup (sym)>" which I have never seen
<sneek>mwette, lechner says: / why does cstruct-select return a procedure, please?
<lechner>sneek / later tell mwette / nvm, i'll go with hash tables for now
<sneek>Will do.
<ArneBab>Does one of you have patches to guile-lint that make it build? I tried to package it for Guix but it fails to build: https://user42.tuxfamily.org/guile-lint/guile-lint.html#Installing
<sneek>Welcome back ArneBab, you have 1 message!
<sneek>ArneBab, lechner says: / my issue with alists is they mix data with structure. I decode bitmaps into symbol lists and am currently unclear whether records and vectors would draw that line more clearly