<ijp>hmm, I seem to have introduced a bug when cleaning up the commits, I hate it when I do that <ijp>hmm, weird, it seems to be loading ice-9/threads <ijp>okay, nothing has broken since earlier, I'm definitely getting to the end of the file, and everything is pushed to gitlab <ijp>zv: it is interesting that you brought up that day, because I was thinking about the unums conversation recently when talking with a numerical analyst <bavier>trying to use (system vm program), find out that 'program-arities' is unbound <bavier>I guess 'program-arguments-alist' works, instead of 'program-arities' ***Amynka_ is now known as Amynka
***do is now known as w1gz
<ennoausberlin>Hello again. What module needs to be loaded to use peg-patterns? <lloda``>I don't use it, but grep says (ice-9 peg) <ArneBab>is there a way to call apropos in a way which searches not-yet-loaded modules? ***snap-l is now known as cmaloney
***do is now known as w1gz
<ijp>hmmm, I think I have been handling keyword arguments incorrectly ***do is now known as w1gz
<ijp>wingo: can I clarify my understanding of keyword arguments? <ijp>suppose I have a function (define bob (lambda* (wibble #:optional wobble #:key splat) ...)) <ijp>if I call the function (bob #:splat), then #:splat is our required argument, but if I have (bob 'goes #:splat) is #:splat supposed to be parsed as the optional or the keyword <ijp>I think I am parsing it as the optional, but it is supposed to be the keyword (and hence an error) <ijp>and once you've started parsing keywords, then anything after is treated as a keyword? so you don't have (bob 'goes #:splat 'sometimes 'whoops) the same as (bob 'goes 'whoops #:splat 'sometimes) <ijp>I thought that my keyword parsing was obeying these rules, but apparently I am sometimes treating keywords as optionals <ijp>I might hack this for now, but I think my argument handling is going to need a rethink <ijp>I don't know if it would break something, but we probably could fix it so that keywords and optionals can be mixed <amz3>it seems like it doesn't work <amz3>sorry, I am preparing an example code that show how I am handling args, rest, keyword and rest keyword argument in my python->javascript compiler maybe it might be helpful to you <ijp>amz3: I know how to do it, it's just I'm very conscious of my time right now, and I don't want to make any large changes <amz3>I got disconnected, 20:10:10 amz3 | the example doesn't use keyword argument because to my suprise it's not implemented in pythonium │ <amz3>20:13:17 amz3 | basically, at call site, compiled functions takes a list of arguments per usual in order to make it possible to ffi easily │ <amz3>20:14:54 amz3 | again at call site, if the python function takes keyword arguments or keywords rest they are all packed into a single JSObject │ <amz3>20:17:12 amz3 | an unique object called __ARGUMENTS_PADDING__, it is in reality a sentinel separting positional arguments from keyword arguments │ <amz3>20:17:41 amz3 | is placed at the end of the positional arguments ^^ and after it comes the keyword JSObject │ <amz3>20:17:53 amz3 | (cf. the bottom of the js file) │ <amz3>20:18:23 amz3 | Then every function definition has an 'unpack arguments' preamble │ <amz3>20:19:03 amz3 | first we check for keywords arguments sentinel (called __ARGUMENTS_PADDING__) <amz3>ijp: do you want me to explain or not? <amz3>just to finish, if the sentinel is there, we know the arguments before are required positional arguments and any rest positional arguments <amz3>after the sentinel there is the packed keyword and keyword rest arguments <amz3>you have to separate them into there respective variables <amz3>same for required positional and optional positional arguments <amz3>same for required positional and rest positional arguments <amz3>I don't know if guile support rest positional arguments when there is keword arguments <amz3>the advantage of this approach is that calling a javascript function from Guile will have no overhead <amz3>in python->javascript there is an overhead because python has a particular semantic regarding calling (a callable can be a function or another object with a class a stuff) <amz3>(it can also be a metaclass) <amz3>ijp: I backlogged, my answer: as you wish <ijp>guile does support rest arguments, but iirc it just assumes that all the keywords are rest arguments <ijp>amz3: guile has an issue that python won't, which is that keywords can also be positional arguments <ijp>if it were otherwise, everything would be much nicer <ijp>this was the crux of my bug, that it wasn't clear that keywords couldn't be *optional* positional parameters <ijp>when you can clearly delineate the keywords, then you just pass around a dictionary like some js libraries <amz3>afaict it's also possible to implement positional arguments passed as keyword argument using the thing i described (which is supported by python) <amz3>anyway, I will try to do it if you don't <amz3>a python function can have the following signature: my_function(a, b, c, *rest, e=42, f=101, **keyword_rest) <amz3>and you can call it as you wish mixing keyword and positional as long as positional comes before keywords <ArneBab>A python3 function can force separation of positional and keyword arguments via f(a,b, *, c=d, **e) <ArneBab>afaik python2 forced using *args after any keyword argument <amz3>fwiw I don't understand the new * feature you describe, i thought it was to ignore some positional arguments <amz3>to keep backward compatibility <amz3>when upgrading some code without having to change the call site <ArneBab>amz3: as far as I understand it, it ensures that the keyword arguments cannot be hit by positional arguments <amz3>because the positional called as keyword, is a feature to document function calls <amz3>so it seems counter intuitive to forbid it <ArneBab>the advantage of this is that you can later add optional positional arguments without getting into ambiguity <ArneBab>amz3: assume that we have f(x,a=0). I can call that as f(1, 2). Now you want to add an optional y parameter: f(x, y, a=0). If someone called your function with f(1, 2), the code will now be wrong. <ArneBab>if a is keyword only, this cannot happen. <ArneBab>you could still call the positional like a keyword, though: f(x=1, a=2) would work and would stay stable after the change. <ijp>amz3: I don't think you understand my complaints <ijp>if guile's functions were as straightforward as python's, this issue would have never arisen <manumanumanu>OK: what is a good macro naming? What I have now is in-range for increasing AND decreasing ranges. The problem is that it is potentially slow in when the direction isn't available to the optimizer. As it is right now I have two support macros in-range+ and in-range- <manumanumanu>in-incr-range and in-decr-range as complements to the regular values one? Or in-range being only increasing and in-reverse-range being decreasing and then having a third one that does both at potential cost? <ijp>manumanumanu: you could make it a (keyword) argument to the (in-range ) form <ijp>similarly if you wanted to allow changing the step value, making the end includive, etc. <manumanumanu>ijp: it is already: (in-range end) (in-range start end) or (in-range start end step). And it is only slow when step is not known to the optimizer <bavier>sad day, no guile package for android Termux <ijp>anyway, I did fix the keyword parsing, but I'd still like to do a rewrite later ***Amynka_ is now known as Amynka
<ijp>okay, so now it works with boot-9 completely unmodified, but you do have to increase the stack size but I'm not 100% sure why