*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 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>as far as I know you need (ice-9 optargs)'s #:key to use it along with define*/lambda* <wleslie>ice-9 optargs doesn't seem to support passing arguments either positionally or 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) <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>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>in wleslie's example, I can't do (copy-file this-src #:user "wleslie" #:dest "/media/wleslie/the-usb") afaik <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") <wleslie>paron_remote: now I can't use src or dest as keyword arguments. <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>copy_file("/home/wleslie", user="wleslie", dest="/media/wleslie/the-usb") works great. <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) <paron_remote>please_help: but I want also src and dest to be mandatory <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>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>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 ***wleslie is now known as protocol_fairy
***michel_mno_afk is now known as michel_mno
<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>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 <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 <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 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 <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>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. <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 2.1.0.331-fe7ec'. I am compiling from git sources 'git://git.sv.gnu.org/guile.git'. How would I go about making it compile v2.2? <lloda>have you run ./autogen.sh on the top directory? <thomassgn>yes, I use the following snippet: './autogen.sh && ./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>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. <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>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>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>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. <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>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>(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) ? <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>I sometimes wish I had time to make a toy Scheme to play around with such ideas <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 <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