IRC channel logs


back to list of logs

<paron_remote>couldn't really figure it out, I eventually just ended up with duplication ;\\
<paron_remote>but it works at least :)
<paron_remote>I'll figure it out at some point I guess.
<nalaginrut>morning guilers~
<paron_remote>hi nalaginrut
*paron_remote doesn't really feel like working on his libreplanet talk!
<paron_remote>I kind of would rather just work on this guile library I'm hacking on instead :)
<paron_remote>I'm slowly becoming better/less bad!
*paron_remote thinks he might like python's keyword arguments handling better in the sense that positional arguments can also be passed in by name
<please_help>#:key does the same thing, right?
<please_help>from (ice-9 optargs)
<nalaginrut>or define* or lambda* ;-)
<please_help>as far as I know you need (ice-9 optargs)'s #:key to use it along with define*/lambda*
<please_help>might be wrong though
<wleslie>ice-9 optargs doesn't seem to support passing arguments either positionally or by name
<wleslie>it's just nicer arguments by name.
<please_help>(use-modules (ice-9 optargs)) (define* (the-function #:key (x 0) (y 100)) ...) -> (the-function 10 3) | (the-function #:x 30 #:y 1000)
<wleslie>oh cool
<nalaginrut>well, you don't have to import (ice-9 optargs) to use define*
<please_help>(define*) can indeed use #:key without (use-modules (ice-9 optargs)), and #:key doesn't seem to support positional arguments (so e.g. (the-function 10 3 is not valid))
<paron_remote>please_help: not totally, in python you can do
<paron_remote>def copy_file(src, dest, user=None, group=None):
<paron_remote>and then invoke like
<paron_remote>copy_file(this_src, dest), but you can also do
<paron_remote>copy_file(user="monkey", src=this_src, dest=this_dest)
<paron_remote>so even positional arguments can be invoked as if keywords
<paron_remote>which can be really nice if you want mandatory parameters, but might want to invoke them in a way that looks more declarative
<wleslie>or even copy_file("/home/wleslie", user="wleslie", dest="/media/wleslie/the-usb")
<please_help>you can mix key, optional and non-key parameters, but you just can't use key arguments as if they were optional ones
<please_help>I think chicken allows it with their extension though.
<paron_remote>please_help: how do I do (foo #:positional "foo")?
<paron_remote>it seems to break
<paron_remote>in wleslie's example, I can't do (copy-file this-src #:user "wleslie" #:dest "/media/wleslie/the-usb") afaik
<please_help>(define* (the-fn a #:key (b 0) (c 0)) (+ a b c))
<please_help>works for me
<paron_remote>please_help: but this doesn't:
<paron_remote>(define* (this-copy-file src dest #:key user group) (list src dest user group))
<paron_remote>(this-copy-file this-src #:user "wleslie" #:dest "/media/wleslie/the-usb")
<paron_remote>give that a try :)
<wleslie>paron_remote: now I can't use src or dest as keyword arguments.
<wleslie>please_help: ^
<please_help>obviously, since you described dest as being non-key
<paron_remote>please_help: but my original comment was that I *can* do that in python.
<paron_remote>and it works fine
<paron_remote>that's my comment
<paron_remote>copy_file("/home/wleslie", user="wleslie", dest="/media/wleslie/the-usb") works great.
<paron_remote>it's not a killer feature
<paron_remote>but it is nice.
<please_help>that's what I said earlier, what you want to do is (define* this-copy-file #:key src dest user group) ...) and then (this-copy-file a #:dest b #:user c #:group d)
<please_help>which is possible in chicken's extention
<paron_remote>please_help: but I want also src and dest to be mandatory
<paron_remote>and positional args make that easy.
<paron_remote>I could write new define syntax to work around it theoretically
<paron_remote>but it's nice that this works this way out of the box in python. but I think python's args/kwargs support is probably the nicest of any language I've seen, maybe.
<nalaginrut>it's just syntax-sugar, even define* is not a part of Scheme
<nalaginrut>you can construct anything more powerful with macro
<paron_remote>sure, but lots of guile things are sugar.
<paron_remote>I'm just saying it's nice the way it is in python, not that guile is killed by not having this by default :)
<nalaginrut>yes, sugar is fine, but it's not enough to say a language 'nicest', since any sugar could be constructed in Scheme in principle ;-)
<paron_remote>I didn't say that
<paron_remote>I said it was nice in python
<paron_remote>no nice-est
<paron_remote>well, I did say the *arg **kwarg is maybe the nicest
<paron_remote>but not that the language is.
<paron_remote>which, I think that it's true that the default handling is nicest there.
<paron_remote>that doesn't mean it's the nicest language or that you couldn't do it in guile, which I haven't claimed!
<nalaginrut>well, I mean kwarg is sugar, so it could be nicer if you really want
<nalaginrut>but it's not worth to argue this issue ;-)
<paron_remote>I already agreed it was sugar!
<paron_remote>so yes I think there's no need to argue
***wleslie is now known as protocol_fairy
***michel_mno_afk is now known as michel_mno
<civodul>Hello Guilers!
<wirrbel>is there an explicit None/NULL/Nil value in Guile?
<taylanub>wirrbel: you can return zero values (in which case trying to acquire a value at all will be an error)
<wirrbel>context: (define* (myproc #:keys (a #f)))
<wirrbel>here I always consider a to be a boolean if I use #f which seems to be common in a lot of scheme code , or with '() I think that the parameter is a list-type...
<taylanub>wirrbel: you can use case-lambda if that helps
<wirrbel>in my use case I guess it won't
<wirrbel>so canonicallly I should probably use '() right?
<wirrbel>I just want some value with the semantics of "undefined"
<taylanub>if #f is a valid value and you want to distinguish between a value and no value, then you'll have to use case-lambda, or pass another argument saying provided/not-provided, etc.
<taylanub>but in most cases #f is not a valid value so it can be "abused" to mean no value
<taylanub>which works well with if-statements and such
<taylanub>case-lambda example:
<taylanub>(define foo
<taylanub> (case-lambda
<taylanub> (() (foo #f #f))
<taylanub> ((arg) (foo arg #t))
<taylanub> ((arg provided?)
<taylanub> (if provided?
<taylanub> ...
<taylanub> ...))))
<wirrbel>I am porting a library at the moment with a function with many optional parameters
<taylanub>think about it: you use a special "no value" value, then eventually hit a case where you literally want to provide the "no value" value as a value, and you're at step 1 again. :P so I find it fine that Scheme doesn't bother defining some "no value" value, and in some common cases #f is just abused for it.
<wirrbel>Its python code, where arg=None is fairly common
<taylanub>I see
<wirrbel>combinatorial, the case lambda is kind of expensive
<taylanub>well, you could create your unique no-value object to represent Python's None
<wirrbel>could I overload its treatment in if?
<wirrbel>(thats more a question out of curiosity)
<wirrbel>the more I think about it, '() seems most appropriate and schemish
<taylanub>I wouldn't say so. that's the empty list object.
<taylanub>I would probably do (define-record-type <python-none> (python-none) python-none?) and use that
<taylanub>(if (python-none? arg) ... ...)
<taylanub>if it won't be exposed to the outside world you could just call it none, without the python prefix
<taylanub>and no, `if's behavior on objects cannot be altered. #f (and #nil for Elisp integration) is false, all else true
<taylanub>... you *could* abuse #nil here, but please don't do that :P
*taylanub goes AFK
<ArneBab>paron_remote: the ability to use positional arguments as keywords in Python means that you can never change the names of positional arguments without risking to break the API.
<ArneBab>paron_remote: so it is a design decisions which I’m unsure about
<ArneBab>wirrbel: how about unspecified? (I’m trying to find out how do write it as literal at the moment…)
<ArneBab>but I guess the version from taylanub is cleaner
<wirrbel>paron_remote: Python apis that build upon *args, **kwargs are also the hardest to understand
<wirrbel>we tend to think of easy / hard as a one-dimensional spectrum, but think of it as a two dimensional spectrum with simple/complex as one axis and easy/hard as the other
<wirrbel>then *args, **kwargs makes a lot of things "easy"
<wirrbel>but they become complex
<wirrbel>whereas you usually want to strive for simplicity, to avoid complexity
<wirrbel>there is a great talk by Rich Hickey on this "Simple made easy"
<taylanub>ArneBab: indeed I forgot about that, but IMO *unspecified* shouldn't be used anyway. I see it as an artefact of the standards failing to specify zero return values.
<taylanub>the other day I got lost in ideas again and it resulted in
<ArneBab>taylanub: I think (ignore (foo)) could make code harder to read when many functions are called for side-effects. It would have to be used in every line for functions which only use (write).
<ArneBab>(at least as far as I understand your idea)
<ArneBab>taylanub: what do you mean by multiple-value returns not being first class?
<taylanub>ArneBab: a procedure called for side-effects will return zero values
<ArneBab>taylanub: so (define (foo) (write 1)(newline)) would not throw an error?
<ArneBab>I like it that you’re trying to unify values-handling into a simpler scheme.
<taylanub>ArneBab: that would write 1\\n and return zero values. it would only error if (write 1) returned any values (which under my proposal it doesn't)
<taylanub>sadly it's not even standards-compliant, let alone backward compatible :(
<taylanub>(well, it can't be backwards compatible because the whole point of it is to make some bug-prone practices to be errors. it's backwards compatible with code that follows certain best-practices, which don't seem very widely adopted though.)
<taylanub>ArneBab: with "MV aren't first class," people mean that they break the intuition that (foo (bar)) will indiscriminately pass bar's result to foo. one could argue about whether it's "fair" to call them "not first class" for breaking that intuition, but one way or another their point stands.
<thomassgn>Hi, I am trying to get guile-2.2 compiled from source. Configuring and compiling goes ok, but when I run './meta/guile -v' I still get 'GNU Guile'. I am compiling from git sources 'git://'. How would I go about making it compile v2.2?
<lloda>have you run ./ on the top directory?
<thomassgn>yes, I use the following snippet: './ && ./configure && make -j3'
<lloda>ah, I see. That's the correct version string for the master branch HEAD.
<lloda>It won't be 2.2 until release.
<thomassgn>ok, can I get 2.2 from a branch or something?
<lloda>there is no 2.2
<lloda>when we talk about 2.2, we mean the master branch that will become 2.2 at some point
<thomassgn>My goal is to use artanis (web application framework), but it tells me something about guile 2.2. I'll ask them about it.
<thomassgn>thank you for the help, lloda
<lloda>it means 2.1. It's the same. You're good with the version you're compiling.
<lloda>*bless erc accidental paste protection*
<ArneBab>taylanub: how would I define what the procedure returns?
<ArneBab>taylanub: why can’t bar just return a list and let-values assign that list to the values?
<ArneBab>what’s the rationale for making them specially?
*ArneBab is now reading
<ArneBab>hm, so your idea would mean to always return values, right?
<ArneBab>essentially making values the default return-statement.
<ArneBab>(with that it could be useful to make it an error if a (values ...) statement is not in tail position)
<ArneBab>taylanub: These were the only places I stumbled over - I like the rest a lot.
<ArneBab>taylanub: could you summarize your idea?
<ArneBab>there seem to be a few different areas which are touched in your text
<ArneBab>I’ll try to write what I understood
<ArneBab>1. always return with (values ...)
<ArneBab>2. provide reflection capabilities to find out the arguments a procedure takes and the values it returns.
<ArneBab>3. add optional caller values to get symmetry between defining and calling functions.
<ArneBab>4. values compatible with apply
<ArneBab>taylanub: did I understand that correctly?
<taylanub>ArneBab: WDYM with how to define what a procedure returns? (obviously it returns what the last expression in the body returns...)
<taylanub>ArneBab: having to use let-values means the first-classness is broken: we had to treat bar's result in a special way... (I'm not sure I agree with this position, but it has a point)
<ArneBab>taylanub: I mean a function to ask for that: (procedure-count-return-values proc) → 2
<taylanub>generally, the documentation will tell...
<ArneBab>ok, so that wasn’t part of what you’d want.
<ArneBab>(I thought it was, because you want to be able to use provided procedures)
<taylanub>procedures passed to an API just have to conform to the rules of that API; my proposal isn't concerned with the API-implementing library's capability of verifying whether the procedures conform to the rules. it's only concerned with allowing more flexible rules, so to say.
<dsmith-work>Happy Friday, Guilers!!
<ArneBab>taylanub: what would your summary of your document be?
<taylanub>ArneBab: I thought my document was relatively clear actually; I guess I'll refine it a little :-)
<ArneBab>I was unsure in the end whether I understood the big picture
<taylanub>it's several ideas actually, some perhaps entirely unrelated to others
<taylanub>Oh, I do have headers for those
<taylanub>1. return zero values instead of unspecified, & non-tail body continuations error on non-zero values 2. not only can formal parameter lists specify optional arguments, but also one can pass optional-to-handle arguments to an unknowing procedure. 2.5. the same, for kw args. 3. a distinct type that reifies the arguments passed to a procedure (aka values passed to a continuation), since mere lists
<taylanub>cannot express the optional and kw ones
<taylanub>(when I say an "unknowing" procedure, that's not a typo: the procedure doesn't know anything about any superfluous values it *could* have taken if its formal parameter list were longer, neither does it know that some arguments it *did* take (if its formal parameter list is long enough) were actually optional)
<ArneBab>ah, ok: values instead of lists to allow for optional and keyword arguments.
<ArneBab>so you need an apply function which can work on values and do the right thing for optional and keyword arguments?
<ArneBab>for 2: does that mean you want to decouple the arguments from the caller and the callee?
<nalaginrut>is it correct to make null pointer with (make-pointer 0) ?
<please_help>why not use %null-pointer ?
<nalaginrut>alright, I didn't know it, thanks
<taylanub>ArneBab: WDYM with decouple? I don't have experience with compiler programming, but the way I understand it there's already nontrivial orchestration done on every procedure call where the procedure is not statically known, primarily to raise meaningful errors on wrong-number-of-arguments, and that orchestration would just need to be improved.
<ArneBab>taylanub: that orchestration is what I mean.
<ArneBab>taylanub: decouple: make the arguments more like their own entity: They are defined by the caller, then they get refined for the callee and finally passed on.
<ArneBab>the caller doesn’t know which of its arguments will be used and the callee doesn’t know which arguments it never saw.
<ArneBab>(though I think that it might be important to be able to inquire which arguments will be used)
<taylanub>ArneBab: while the callee is conceptually (as far as the language user is concerned) ignorant to what received values were optional and/or what values got dropped, the actual code would reside in each procedure (callee) as a prelude I suppose, akin to the code emitted by a use of case-lambda if I'm not mistaken
<ArneBab>the code could also lie in the caller: (apply-to-filtered-args proc args) ← this would require something like (inquire-args proc) which returns the argument definition of the function.
<taylanub>hm, that's right, never mind
<taylanub>I sometimes wish I had time to make a toy Scheme to play around with such ideas
<ArneBab>can’t you do that in guile?
<taylanub>guile's code base is big and scary :)
<ArneBab>create a (taylanub-define) macro which defines a procedure and adds information about the arguments.
<ArneBab>I think it should be possible to implement all these ideas without going into the guile core (and if it isn’t I’d consider that a bug ☺)
<taylanub>I would rather like to see the mechanism implemented low-level, as efficiently as possible, since it concerns a fundamental feature such as procedure calls
<taylanub>though maybe that's unnecessary to compare the essential complexity
<ArneBab>I think so - I’d rather guess that the main work would be to make all different aspects of Scheme consistent with that. Lots of tedious but important work.
<ArneBab>it should at least suffice to create a working prototype
<ArneBab>sneek: seen mark_weaver
<sneek>I last saw mark_weaver on Mar 19 at 04:54 pm UTC, saying: thanks for working on it!.
***wingo_ is now known as wingo
***michel_mno is now known as michel_mno_afk
<wirrbel>the texinfo guile doc is really more than uncomfortable, compared to output of other documentation systems (linke python's sphinx, etc.)
<wirrbel>I am not whining about the content here ( which is great), but about the ancient HTML output and the heavy nesting
<sirgazil>Hi :)