<manumanumanu>Nothing in particular. Learning common lisp and porting whatever I like from it to guile <pmikkelsen>I am woring on writing a meson-build-system for guix, so we can hopefully get the latest gnome when/if they switch ;) <amz3>I shoud also work on ffi helper <amz3>(at the present time I am at work, and I don't work on guile ;) <manumanumanu>I am not a very good programmer (classical musician by profession), and I feel a bit sad I can't really contribute to most oss projects. The guile for-loops I wrote are about as complex as I can write <manumanumanu>(but I am proud of those. they work very well, and produce optimal code in most cases) <pmikkelsen>manumanumanu: I am confident you can contribute to guix if you want to, but if you don't use it, maybe it is not so fun ;) <amz3>manumanumanu: fwiw I am programmer by trade and I don't feel like I am up to the task of writing for-loops <amz3>manumanumanu: you have imposter syndrom ;) <gour>is it reasonable tp expect that one could use guile for configuring emacs in the foreseeable future or am i better learning some elisp as well? otoh, my interest for guile is to use it with gnucash as well as to possibly migrate to guixsd (from fedora) if i manage to find compatible hw not requiring special firmware <pmikkelsen>Last time i used that guile emacs, it was not very fast, but it may have had something to do with how it was build. Although I can highly recommend learning guile for guixsd, and even just for guix on fedora :) <gour>pmikkelsen: yeah, guix on fedora might be a good step into right direction <gour>as far as guixsd, wifi drivers are probably the only/main obstacle since i anyway have/use old ati cards with floss drivers <pmikkelsen>gour: yeah wifi.. I was really lucky that my system had hardware that just worked out of the box, wifi and all ;) <civodul>wingo: i just emailed you with more data re compiler profiling :-) <civodul>i'll be away for several hours, but i'd be happy to read your thoughts! <wingo>i will look at it as soon as i can! :) <wingo>ACTION was hacking on removing the indirection in structs this morning <wingo>but to do that, class redefinition needs to be reimplemented; so i made it so that class redefinition is a layer on top of "fixed" classes <wingo>which is a relief in many ways, as redefining <class> itself is terrifying <wingo>so after this change, we still have redefinable classes, but only some classes are redefinable <wingo>and the new thing is that after the change, we can have proper goops classes for fixed structs without the indirection <wingo>and then structs remove their indirection and weird GC interaction, and then "instruction explosion" can do a good job for structs <wingo>ACTION has been agonizing over this for months :P <ecraven>wingo: say I wanted to add the simple parts of r7rs to guile (boolean=?, string-for-each, let*-values, such things). where would I start? is there a file where r7rs compatibility code should live? <ecraven>exact / inexact for inexact->exact and exact->inexact would be simple too, for example <wingo>i do not know :) would require more thought than i have at the moment. some things like exact->inexact should probably just be renamed in the root env. some things like let*-values are already part of a srfi. you can obviously define a module that exports precisely the r7rs interface... <wingo>but what the overall guile/r7rs story looks like, i don't know. other people have thought more about this than me. <wingo>i suspect that we need a command-line arg for --r6rs or --r7rs, something like that, where guile will have r7rs small support built in probably <wingo>and --r7rs will expose that module <wingo>but for the large modules i expect most to remain as 3rd party libraries as they are just libraries <wingo>but that is just an ignorant thought :) <ecraven>wingo: it might be "good enough" for starters to at least have the correct names in the initial environment? <ecraven>especially for existing things that were just renamed in r7rs <ecraven>wingo: yea, not thinking about r7rs-large yet ;) <wingo>i think we probably will not expose string-for-each in the default env, for example <wingo>but with --r7rs we would arrange for that to be the case <ecraven>so the way to go would be to create something like an r7rs-compat module, that re-exports existing functions under the right names? <wingo>yes i think that's the right way to go, yes <wingo>we can always integrate more tightly with time if that becomes a good idea <wingo>hard to remove added interfaces though! <ecraven>my interest is mainly poking all Schemes until there is at least *some* way to get an r7rs-small environment ;) <ecraven>I'm not saying guile should move to r7rs entirely, but it would be nice to have some way to get at least r7rs-small (which [apart from import] shouldn't be too hard, as everything is probably there already, just not under the right bindings) <ecraven>is there some place in ~ where I can put guile modules so that guile will find them? <gour>ecraven: thanks a lot! it seems there is no lack of scheme implementations. ;) noreover, it's interesting to see that chez is very quick and racket dpes plan to depend on it in the future... <ecraven>gour: just remember that there are many things you *don't* see in those benchmarks <gour>ecraven: yeah, benchmarks are always tricky...just wonder is it difficult to switch 'context' if one wants to use different implementations of scheme like guile/racket...? <ecraven>depends on what programs you write, but for anything even remotely complicated, you will have to use implementation-specific code, and that makes things much harder to port <ecraven>r7rs-large is trying to change this (very sloooowly ;) <gour>does r7rs includes racket as well or is it too different? <ecraven>racket has a compatibility mode (which isn't perfect yet) <ecraven>I think the only implementation that is entirely r7rs is chibi <gour>what would be some scheme implementation suitable as kind-of python replacement for writing tiny scrpts and/or cli utilities? <ecraven>most of the larger ones are suitable for that ;) <ecraven>gour: my suggestion would be, start with one (guile isn't a bad choice here), look how you like it <ecraven>if you find features you need, but which guile doesn't have, either implement them yourself, or look at other implementations <ecraven>but guile has tons of libraries, you'll find most of what you need pre-made <gour>ok, learning guile would pay of for gnucash reports as well... <ecraven>if you learn one Scheme, it will help you with all others, just the libraries are different <gour>guile's gui is still gtk2? any plan for gtk3 support? <gour>ecraven: but Elisp is a bit different <ecraven>if you know emacs, you should look into geiser <gour>starter with the Emacs...using for general writing, orgmode... <gour>that's why i did originally asked about Emacs & using Guile for it :-) <gour>let me use-package for geiser... <gour>i know that racket has its own multi-platform library...but wonder any other scheme could be suitable for writing multi-platform (although linux is my native platform) desktop app (i hate JS and browser apps) with good support to bind 3rd party C libs? <ecraven>again, most of the larger ones have some sort of bindings to GTK or QT or so <gour>i'm excuse for being ignorant, but i'm aware only of racket's gui. :-( <ecraven>gour: well, it depends on what you want to do. what kind of application do you want to write? <gour>ecraven: 'typical' desktop app, using 4rd party lib to speed up some computations, having sqlite3 as storage back-end... <manumanu1>amz3: haha, like in all other parts of my life. But anyway, the for-loops are easier than hey look. You can get 98% of racket's functionality with a quarter of the code. ***manumanu1 is now known as manumanumanu
<manumanumanu>are there any non-slow way of comparing symbols/keywords < > = ? <manumanumanu>how are they represented internally? Is converting to and from strings expensive? <civodul>manumanumanu: symbols and keywords are "interned", meaning you can compare them with 'eq?' <civodul>and 'eq?' is pointer comparison (very cheap) <manumanumanu>civodul: the thing is, I have been using them as keys in an assoc, and I need to sort them :) My option seems to be to convert them to strings, but that seems rather expensive <civodul>quizz: which of the following options consumes less memory? <civodul>probably the first string, followed by the 2nd list, followed by the 1st list <civodul>this one is a simple example, but i was wondering about this in the context of a big CPS dump <cmaloney>Wouldn't the list of symbols be using different memory? <civodul>cmaloney: symbols are interned, so the amount of memory used depends on the frequency of occurrence of these symbols <stis_>analyzing python constructs and what it means for scheme, also a python->scheme compiler <stis_>for example an object system that i similar to python and how to make a similar exception mechansims as in python using goops <stis_>I've also hacked guile to autocompile python files, in discussion to get it into mainline <stis_>e.g. not python but the nessesary code stubs that must be included in guile in order to get autocompilation of multiple different langugages working <manumanumanu>stis_: ported a piece of common lisp code for working with ID3 and Vorbis tags <manumanumanu>the whole tagging part is still too wonky, but there are some stuff I can see myself reuse <stis_>really don't know, but I think that plists is used in the guile compiler though as a list of directives <dustyweb>tl;dr "there's no fundamental difference between them, just convention, but plists tend to be mutated while alists don't" <manumanumanu>dustyweb: hmmm. thanks.using plists with apply works in guile as well. <stis_>listening to music and writing about functional programming for my relatives on facebook (I live in another city) <stis_>it's cool to try to write with words so that even my mother understands. <manumanumanu>I can't even get my .net-programming friend to understand what macros are. Probably my fault :( <stis_>I think that macros are more difficult to explain in order to show it's uses, generally it just means that your language can be tiny and that your programming experience can be infinitely rich. <stis_>the drawback is that people have a hard time seeing what the macros does from source code in case they are complex and under documented and you end up having hard time understanding the code <stis_>but using advanced functions abstractions also have this problem so donugh, when you don't want the applicativiness of a fucntion or bind variables it's a must else functins usually is fine <stis_>My focus on functional was the ability to frreeze instruction and pass it to a rotine that can execute it at the right places e.g. higher order programming and show why python is not especially functional because the yield statement is local to the function frame, and non tail calls means that you cant make some abstarctions with functions <stis_>actually I added the ability to place a yield in another frame inmy compiler and also the functions are the proper scheme tail call ones <manumanumanu>stis_: I managed to explain them by example, to which he replied "we do that wih templates". At least until I showed him the for loops :D :D <manumanumanu>dustyweb: hmmm. the alist stuff in scheme very much lends itself to mutation, and not in a very pretty way. <manumanumanu>whereas, writing your own persistent alist/plist is pretty simple <dustyweb>manumanumanu: I mean, any of these things can be mutated. <manumanumanu>of course, but the way to work with alists lends itself much better to a mutable way <dustyweb>manumanumanu: like I said, it's convention, if anything, and the convention is not as strong in scheme land because mutation is somewhat more frowned upon here than in common lisp <dustyweb>but that, too, is convention of the community, since nothing in scheme stops you from mutating like crazy. (at least we have the ! suffix though)