<ArneBab>Is there a practical Scheme tutorial which explains how to work with records and where to use them (convenience-wise and performance-wise)? <amz3>ArneBab: records like srfi-9 records? <amz3>I am not aware of any tutorials regarding records per se <amz3>what I know is that a) last time I asked which record library to use on #scheme, I started somekind of flamewar over hygenic and unhygenic macros b) I like srfi-9 c) there was lot of debate about records in the past, it's a sensible subject but I have not sources about it d) I think srfi-9 are based on vectors, they are basically "tagged" vectors except they appear not as such in ice-9 'match' which is handy <amz3>e) another debated subject regarding records is whether they should support some sort of inheritance <amz3>g) there is also a gnu extensions to srfi-9 lookup for 'gnu' in srfi-9 guile manual page <amz3>like you can define a specific printer for a record type (the equivalent of overriding __repr__ in Python) <amz3>BTW, records are coming to python stdlib they are called data classes, same for fluids which are called context vars. <amz3>regarding d) guile srfi-9 records are a _disjoint type_ <amz3>hence for ice-9 match srfi-9 records and vectors like vu8(42 3.14 1337) are disjoint <amz3>aka. you can not match a record by mistake using some vector pattern <amz3>regarding performance I am not sure, IIRC mark wrote that srfi-9 gnu immutable records are faster but I am not sure. <amz3>Also there is some helpers to instrospect records, but I never made use of those procedures. ***Server sets mode: +nt
***Server sets mode: +nt
***geokon1 is now known as geokon
***rekado_ is now known as rekado
***slyfox_ is now known as slyfox
<jlicht>`coverage-data->lcov' from (system vm coverage) does not support the `modules' keyword in guile 2.2. Was support for this removed, or is the info-documentation simply incorrect? <amz3>jlicht: it must re-implemented, look at the module file there is note about it and it's commented <amz3>in the source file i mean to say <amz3>I got confirmation from civodul that it a task that remains to be done <jlicht>amz3: thanks! I did not realize the comment was also referring to the same thing <stis>muu as the swedish cows says <stis>and don't let me write here what I learned my children about pig sound (close to a snooring sound) <ArneBab>amz3: the different kinds of records <stis>manumanumanu: would be fun to hava a hackaton here about something, like testing and helping jit, guile-emacs or such a ganeral interesting topic <amz3>ArneBab: IDK if there is a comprehensive study of records <wingo>would be cool if someone made a notebook with guile <civodul>wingo: guix package -i jupyter-guile-kernel :-) <civodul>more to come in this area in Guix land... <amz3>notebooks are the future *wingo implemented fused compare-and-test in the jit, to better work with lightning api <mwette>re records, check amazon for books on "functional data structures" <manumanumanu>stis: the thing we are doing in Linköping is more to show off cool stuff, but for a future thing that is a wonderful idea! <manumanumanu>i guess hugo is doing something CSy, so he might actually be useful compared to me <ArneBab>mwette: a full book on datastructures would be a bit much, since I just search for a 3-4 page tutorial which shows where they are useful. Essentially "best practices and why" <amz3>AFAICT, records are used in place of where you would use a dictionary in python or a namedtuple. The difference with a python dictionary which is more like an alist. The difference with the alist is that it's O(1) instead of O(n) to lookup an item, the advantage of the alist is that you can no stuff keys on the fly you must know them in advance <amz3>on my side, I use records also instead of classes. <amz3>on you can even mimick 'abstract class' kind of class by stuffing procedure in record fields <amz3>I have no example of that tho <ArneBab>amz3: from what i saw, the namedtuple is closest, but it seems that I’ll need to check by myself how fast they are and how much memory they need. <ArneBab>amz3: thank you for the examples! Once my children stop complaining that their video is in a small window, I’ll check them :-) <amz3>ArneBab: btw the C struct as record as a bad example, look into guile-git / guile-libigit2, the best way to define disjoint type for pointer is something else that is guile specific, I don't remember correctly <amz3>ArneBab: regarding performance, you can compare to vectors, but I think the performance gain in using vectors instead of struct will be very slim <amz3>instead of records i mean <mwette>Aren't scheme records (usually) implemented with vectors anyhow? <civodul>mwette: conceptually, records are vectors with labeled entries <civodul>in Guile though, "structs" are disjoint from vectors <civodul>the thing is that you need a way to create disjoint type, so you can't really implement records in terms of vectors <civodul>(or you have to override 'vector?', but then it might still be possible to forge invalid record instances, among other issues) <mwette>civodul: one uses slot 0 for the struct name <mwette>usage: (define-mstruct foo a b c) (define x (make-foo 'a 1 'b 2 'c 3)) (foo-a x) ;; => 1 <stis>yay my socket implemented for guile python compiles and loads <mwette>stis: you want to be able to run (pure) python code in Guile? <stis>not all things is supprted like the self inspections code <stis>also I don't supprt assynks as wingos: fibers is the way to go <amz3>jlicht: you get used to it :) <amz3>jlicht: I got used to at least <jlicht>amz3: I was afraid this was the case :(. I could just print out the srfi-97 list and hang it next to my bathroom mirror... <mwette>(lol was to the bathroom mirror ref) <weinholt>jlicht, r6rs code in guile can use srfi 97 names and import (srfi :1 lists) etc, it is translated to srfi-1 and so on <jlicht>weinholt: hah, that is cool! thanks. <civodul>the bathroom mirror trick is a good one :-)