***rt is now known as robin
<alextee[m]>I'm trying to figure out what's the easiest way for creating guile bindings for my c code without having to write interfaces manually like in the manual <alextee[m]>There's also that nyacc ffi helper thing. What would you recommend? <manumanumanu>ArneBab: I don't think people's stance on syntax-case has changed much. <manumanumanu>I don't think much of that is actually very controversial. except the immutable cons pair thing (which IMO is a great thing). <manumanumanu>So... optional arguments are not always a good thing. I just spent 20 minutes looking at ,traces and what-not not understanding why my recursive function was not working properly. The error was in the simplest clause not propagating an argument :( :( <manumanumanu>But now it works! I have a small program reading scribble-like syntax into SXML (with a slightly diverging at-expr). <manumanumanu>lloda: well done. you have been at this for some time, iirc. <tohoyn>can you estimate when we will have Guile 3.0.7 in debian (testing/unstable)? <manumanumanu>It is not quite compatible with racket's version, but close enough for what I'm using it for. <tohoyn>new versions of Theme-D-Golf and Theme-D-Gnome have also been released <leoprikler>manumanumanu: how come @{1} => 1, but @{a} => "a"? Is there some deeper meaning behind that? <leoprikler>i mean it breaks the + example if you don't special-case numbers but it's still weird not to be documented <leoprikler>The Guile interpreter in my head while reading the documentation :P <manumanumanu>Ah. No: there is a difference. Everything between [] or () is scheme <leoprikler>regarding the hash extension, can't you simply (fix-atexp (read-atexp port)) ? <manumanumanu>I don't know what you mean. read-hash-extend extends the guile reader so that it calls my procedure when it finds #@ <leoprikler>sure, I mean the code inside the read-hash-extend <manumanumanu>don't look too closely at the source. it is pretty awful <manumanumanu>I start with point A, where I am now, and some vague vision of point B, where I want to be, and i spaghetti myself between the two. ***apteryx_ is now known as apteryx
***chris is now known as Guest3569
<lloda>(scheme base) redefines a lot of core bindings, shouldn't it be using #:replace ? <lloda>also i dislike srfi-43 intensely <lloda>vector-copy where end can be > the size of the source <leoprikler>how would that work? With python-style wraparound? :P <lloda>no, it just makes a bigger result and fills it with a filler <lloda>i mean it just fills it with a filler, sorry <lloda>when there are many ways to extend the meaning of something, it's time to stop <leoprikler>imagine you want to grow your vector to some larger size while retaining the existing elements <lloda>give your extensions some other names <lloda>you can just make the big vector yourself and vector-copy! in it <lloda>that's what vectors are for /shrug <lloda>and that's what the extension was doing anyway <leoprikler>sure, but you have to differentiate between API and internals <leoprikler>internals can be ew when no one looks at them :P <lloda>i still don't think it's a good extension <leoprikler>Well, it doesn't break compatibility with the existing thing and does extend it in a very defined manner. <leoprikler>you could achieve the same thing with map and basic arithmetic, but having it built-in makes the code read much nicer <lloda>only nit is that the C versions cannot be extended compatibly :-\ <lloda>but the same thing happened already with scm_vector_fill_partial_x <lloda>not sure how to solve it tbh <leoprikler>iiuc the partial copy assumes the destination to be smaller than the source, right? <leoprikler>hmm, seeing how this is defined in terms of vector-move-left!, does vector_move_left_x exist in C? <lloda>leoprikler: logically it's fine and in Scheme there are no issues <lloda>but in C, adding arguments means breaking the previous interface <lloda>that's why i left the C as it is <leoprikler>oh, I didn't know there existed a procedure beforehand <lloda>it's funny in a way bc vector-fill! was already r7rs compliant, but the doc doesn't say it, so the r7rs libraries had their own implementation <manumanumanu>lloda: is that vector fill slower than the C one? I have noticed that some string functions I have rewritten in scheme have been just as fast as the ones in C in guile. If there is no performance penalty, maybe rewriting them in scheme wouldn't be a bad idea. <manumanumanu>I haven't talked to Andy about that, but I have a feeling he wouldn't disagree if there is no real performance impact. <lloda>yeah I don't disagree with that. If the perf is similar Scheme is ofc better <lloda>when you need to provide a C binding then it's a bit more difficult <lloda>tbh I think functions such as scm_vector_fill_x are a bit superfluous since they're just a for loop in C. You can just give the pointer and the size and let C users figure it out <lloda>but once they're in the public interface you have bear them <lloda>I think functions that are loops in C that call Scheme functions are likely always going to be better in pure Scheme <lloda>vector-fill!, vector-copy etc aren't like that, they are raw C <ArneBab>manumanumanu: what is the stance on syntax-case? <ArneBab>manumanumanu: I now provided my enter-three-witchen macros as a benchmark for expressiveness of other macro systems. <manumanumanu>Lets just say some people still whine about it since r6rs :) <manumanumanu>If I would say anything it is that syntax-case is not hygienic enough. Srfi-72 solves a real problem with syntax-case. If I ever understand guile's syntax-case, I will write a (extra-hygienic-quasisyntax <manumanumanu>that will always introduce bindings hygienically unless you are unquoting the same syntax object. <daviid>vijaymarupudi: I just pushed a fix for the bug you reported, g-golf develbranch, please pull, autotool danse :), try and let me know ... <leoprikler>syntax-case is pretty hygienic by default tho, no?