IRC channel logs

2021-12-03.log

back to list of logs

<stis>Hello guilers!
<tohoyn>When I distribute a guile application should I distribute it as .scm source files or compiled .go files?
<ArneBab>taw10: day 2 was nice — defining a minimal language that reads instructions and adjusts variables. Much nicer than my solutions to day 1, but also much hackier …
<taw10>ArneBab: Love it! Here are my solutions (spoilers, obviously) https://github.com/taw10/advent-of-code/tree/main/2021
<taw10>My day3 part2 does too much computation, but it allowed me to re-use the part 1 code better
<taw10>I'm trying to use as much functional style as I can, for practice
<amazigh>re r7rs cond-expand, I do not reproduce with guile from git
<amazigh>and guile git pass my json test suite
<tohoyn>how often does the format of .go files change between different guile releases?
<lloda>iiuc changes are allowed to happen on x.y but not on x.x.y
<lloda>that's like a couple years?
<lampilelo>taw10: another functional way would be to create a binary tree while reading the input, store the number of leaves on every node and then just walk that without having to iterate again over the input
<lloda>what is the most up to date guide to packaging a guile library?
<lloda>i think i'll copy what guile-ssh does
<tohoyn>lloda: tx for info
<Guest387>taw10: not to discourage you, it's easy to write code such as (map proc (filter pred? (string->list str))) but remember each step generates a list which is immediately fed through the next step then discarded. think how you'd eliminate these intermediate lists...
<gbrlwck>i'm puzzled by line 62 in https://git.savannah.gnu.org/gitweb/?p=mes.git;a=blob;f=mes/module/mes/pmatch.scm;h=30e5103a9a2b76d6bbfdffa3fe046fc8c50b2e50;hb=HEAD . does that actually *do* something?
<taw10>gbrlwck: that means "return unspecified" I think
<janneke>indeed (if #f #f) is a portable way to say *unspecified*
<ns12>gbrlwck: (display (if #f #f)) will print #<unspecified>
<gbrlwck>thanks for clarification!
<taw10>Guest387: Thanks, I will think about that. But I do like that the code expresses the calculation in a clear(-ish) linguistic way. I would've approached the problems very differently in C, much more efficiently but less clear. Without giving away any answers (or spoiling anything for people still working on it), do you think it's possible to get the best of both worlds?
<ns12>janneke: Is it guaranteed to work that way across implementations?
<lampilelo>taw10: Guest387: yeah, that's what srfi-171 is for
<taw10>Transducers? I suspected that might be the answer. I will practice with them in the later challenges...
<janneke>ns12: i have do idea ;)
<janneke>but that was my guess
<gbrlwck>it seems to work fine in guile and mes
<ns12>It seems to work find in Guile, MIT Scheme, Chez Scheme, Chibi, and Racket (plt-r5rs, plt-r6rs).
<ns12>s/find/fine/
<dsmith-work>Happy Friday, Guilers!!
<Guest387>taw10 lampilelo: transducers: not my skill, but yes.
***Guest387 is now known as chrislck
<apteryx>is expanding macros into source code generally a lossy process?
<apteryx>because I was surprised to learn it is the case in rust (when compiled, the rustc compiler associates metadata with variables that it uses to avoid shadowing same-named variables -- but such metadata cannot be represented as code (source))
<RhodiumToad>in guile? macro expansion is done as part of compiling to tree-il, but tree-il can be decompiled back to scheme source without, as far as I know, any loss except that variable names may become munged
<civodul>decompilation doesn't "unexpand" macros though :-)
<civodul>so it's lossy in the sense that you can't round-trip
<apteryx>RhodiumToad: munged meaning changed, but not in an unsafe way, correct?
<apteryx>civodul: ah, right. I'm not concerned about about this 'lossy' bit though :-)
<RhodiumToad>right, I don't recall the exact circumstances, but a variable 'foo might become 'foo-somelongnumber
<apteryx>OK! thanks a lot for the info
<apteryx> https://www2.ccs.neu.edu/racket/pubs/cf-sp09.pdf looks like an interesting read
<RhodiumToad>(tree-il->scheme (macroexpand '(some form))) is an invaluable debugging tool for macros
<RhodiumToad>(you need to ,use (language tree-il) to get the tree-il->scheme function)
<apteryx>interesting!
<RhodiumToad>there's some loss in the sense that different scheme forms might produce the same tree-il, in which case the inverse will choose one of those forms, but it should always be exactly equivalent to the original code in semantics
<RhodiumToad>for example, nested (let) forms might become a (let*)
<RhodiumToad>since (let ((a 1)) (let ((b 2)) ...)) and (let* ((a 1) (b 2)) ...) generate the same tree-il
<RhodiumToad>that's kind of cheating a bit since let* is actually a macro, but the tree-il decompiler does in fact "unexpand" it
<lilyp>tree-il->scheme might also hide errors though
<lilyp>particularly if macros generate two different identifiers with the same name
<RhodiumToad>why would it hide errors?
<RhodiumToad>in fact I found it useful when determining that the example in the manual of an anaphoric macro did not work
<RhodiumToad>challenge to macro experts: the ";; better" version of (aif) given in the manual under "Syntax Case" is fundamentally broken; give an example of why
*dsmith-work noticies the sounds of crickets..
<dsmith-work>:cricket:
<civodul>RhodiumToad: it doesn't preserve lexical scoping
<civodul>for instance in (let ((it 42)) (aif (+ 2 3) it 0)), the second 'it' refers to the one introduce "unhygienically"
<civodul>*introduced
<civodul>do i win the prize? :-)
<civodul>the "right" approach would be to use a syntax parameter