IRC channel logs


back to list of logs

<ArneBab>apteryx: :: is INADDR6_ANY
<ArneBab>("::" that is, that’s the ipv6-equivalent to
<ArneBab>or see with
***Furor is now known as Colere
<apteryx>why is it defined as 0 in (shepherd service) then?
<apteryx>that's for IN6ADDR_ANY, not INADDR6_ANY though
<flatwhatson> is 0, presumably :: is also 0
<apteryx>which would mean that INADDR_ANY could be used in place of INADDR6_ANY, which is a bit odd
<Zelphir>What are well liked alternatives to the debian paste in this channel? Debian paste seems broken for me. I would like to create a paste that is acceptable and ask a code question : )
<unmatched-paren>Zelphir: there's
<Zelphir>OK looks cool, will try that one, thanks!
<Zelphir>I have this macro, which is supposed to replace a placeholder <?> in an arbitrarily nested expression: But when I try to use it, it does not seem to work for example for lambda expressions. It always turns the lambda expression's argument list into ((arg)) instead of (arg). (for one argument that is) I don't get why it does that. What mistake do I make?
<Zelphir>I found the following way of debugging my macro: I make every case of the macro quoted. Then I run the macro step by step, taking its output and use it unquoted as an input for the macro again. Each time doing recursive calls. I could not find the mistake that way.
<Zelphir>I'll try to post a debugging attempt.
<Zelphir>Here is the macro with cases quoted: And here is the "debugging session":
<Zelphir>So when I manually "step through", all seems correct. But maybe I am doing something while stepping through, that does not happen in the actual macro expansion. But what could it be?
<Zelphir>(maybe a tangential question: How do you usually debug your macros? Maybe there are better ways than what I am doing.)
<cwebber>hi Zelphir
<cwebber>Zelphir: have you discovered ,expand ?
<Zelphir>:D not yet, let me check it out ...
<Zelphir>Hm. Seems to do exactly what I did with quoting :D
<Zelphir>But also prints things prettier!
<Zelphir>Hm. But ,expand does expand all the way, when I unquote the cases in my macro, leading to the same error.
<cwebber>it does expand all the way
<Zelphir>Have to leave for now. Might ask on the mailing list later :)
<dsmith-work>Morning Greetings, Guilers
***chris is now known as Guest8669
<apteryx>is the #<unspecified> value self-quoting?
<apteryx>dsmith-work: hi!
<apteryx>*unspecified*, rather
<cwebber>apteryx: nope
<dsmith-work>I think (if #f #f) is the common way to produce it. There is no read syntax for it, IIRC.
<cwebber>scheme@(goblins contrib syrup)> (format #t "~a\n" (if #f #f))
<cwebber>scheme@(goblins contrib syrup)> #<unspecified>
<cwebber>While reading expression:
<cwebber>#<unknown port>:736:3: Unknown # object: "#<"
<apteryx>that sucks; we use it it services in Guix and not being self-quoting means it cannot be serialized
<cwebber>a reader extension for guix service usage could be added, if it's important
<cwebber>has it been a problem?
<apteryx>until now it wasn't, but I made a new xvnc service that uses it and 'guix deploy'ing a machine config with the service fails with "guix deploy: error: #<unspecified>: invalid G-expression input"
<apteryx>cwebber: do you think a reader extension for #<unspecified> could be added to Guile proper? I don't see a reason why this kind of value shouldn't be serializable
<apteryx>to me, it's akin to #true or #false; perhaps #<unspecified> could be turned into #unspecified then?
<dsmith-work>It just seems wrong to specify somethiing that is unspecified.
<dsmith-work>There was much debate in the RxRS (can't remember which x)
<apteryx>so perhaps the problem is the (gnu services configuration) module in Guix is using *unspecified* as some way to convey that a value was left unspecified by the user... the previous approach was to use a symbol in this case instead.
<dsmith-work>Some have proposed (values) as an alternative
<apteryx>it's simplifies things in this context if the "unspecified" value can be self-quoting (which a symbol is)
<apteryx>(values) returns nothing; that looses the information when serializing, me thinks
<cwebber>(values) returns 0 values to its continuation, no value at all, which in certain kinds of code where you're checking what a value is (eg using pk) will actually throw an error
<apteryx>that seems perhaps one of the "purity wins over practicality" choices in Scheme? to be able to check and serialize the unspecifiness of a value has real life applications, me thinks
<apteryx>yes, we can use any other specific value to mean that, but having to use 'unspecified instead of *unspecified* seems a bit silly
<apteryx>it seems to have a long history of being debated in scheme :-)
<lilyp>Maybe write value(s)?
<lilyp>so the implementation can do whatever it wants – return one value, return 0, return a triple
<apteryx>the problem is not about having the implementation do what it wants, but about having an ambigous position about whether *unspecified* is to be actively used or just some undefined behavior not to be relied on nor used
<apteryx>the 'unspecified?' procedure in Guile kind of suggests it can have some general use, which seems at odd with Scheme the language which seems to have chosen against making it a proper data type
<lilyp>apteryx: idk, this seems to be the same as "implementation-defined" in C/C++
<lilyp>if Guile has its implementation-defined unspecified? that's valid scheme
<lilyp>in other schemes you usually substitute (if #f #f)
<mwette>(if #f #f) seems to be the canonical way to generate unspecified.
<mwette>I use it in Guile code for compilers (e.g., m-lang) which have functions that don't return a value.
<apteryx>lilyp: so perhaps Guix could have its gexp-compiler that translates *undefined* to (if #f #f) ? not very readable though
<lilyp>I mean it could simply quote *unspecified*, no?
<apteryx>that would work too, and be readable
<apteryx>I think
<dsmith-work>So back in the day, things like set! might evaluate to the new value. Or the old value. The stadards people say "unspecified", so could be either, or something else entirely.
<dsmith-work>Guile returns #<unspecified> for all those things that are specicically unspecified.
<dsmith-work>It really means "don't use this value". Right?
<dsmith-work>Guile does use that value in the REPL print to *not* print the value.