***fangism1 is now known as fangism
*nalaginrut tried master yesterday, took almost 1 hour for compiling <nalaginrut>I'm glad to see rtl was renamed to bytecode officially ;-P <tromey>a few of those .scm files take quite a while to build <mark_weaver>the reason is because the compiler has not yet compiled at that point. <tromey>I mean -- yeah, compiling the compiler can be slow, totally understandable <tromey>mildly curious if checking in the compiled form of the compiler would be appropriate <mark_weaver>one bootstrap interpreter written in C that's used to interpret the fully-functional interpreter written in Scheme, and that's what runs the compiler while compiling the first few files. <mark_weaver>during the build, more and more of the modules of the compiler are compiled, so it gets progressively faster. <nalaginrut>hmm...changed? I thought one for C scheme compiler, and a temporary Scheme scheme compiler, and the final one <ijp>tromey: well, it wouldn't be the first module we did that for. we have a macroexpanded version of the macro expander checked in <ijp>incidentally, one of the files you are taking ages on :) <tromey>there's also the full bootstrap idea -- like compile the scheme compiler to c, then check that in, etc <mark_weaver>the compiled VM code depends on the word size and endianess, and pretty soon (in master) also the maximum architectural page size. <mark_weaver>C is not a particularly good language to compile Scheme into, mainly because of the lack of any way to do reliable tail calls. <nalaginrut>I've heard pypy is faster than cpython, so I guess scheme-scheme is better than c-scheme ;-P <tromey>it's interesting to me how few bugs there are in the guile bug tracker <ijp>we've had it for a while, at least a year <mark_weaver>occasionally, I think that what we really should do is infiltrate the GCC community and add the necessary features to GNU C such that it would be a good target for Scheme compilation. <mark_weaver>however, it would most likely mean adding a new calling convention, because the convention that callers pop the arguments from the stack does not work well with tail calls. <tromey>gcc has tail calls already, perhaps some generalized form is possible. I don't really know <tromey>but this is a good idea for you, IMO <tromey>and second it has worked well for other languages, namely gcj and Go <mark_weaver>last I checked, there's no reliable way to do a tail call in GCC. <mark_weaver>it's merely an optimization that you cannot count on. <tromey>perhaps an attribute making it reliable is possible <b4283>it is ok if i cite something from this channel with names? <mark_weaver>caller-pops-args is a problem, because in the presence of tail calls, the caller doesn't know how many arguments to pop. <b4283>mark_weaver: copy and paste your words on another channel <mark_weaver>the fact that in the general case, C functions might not even know how many arguments were passed to them, is another very serious problem. <mark_weaver>b4283: you can copy my words if you like, as long as it's clear that my words were written on IRC. <tromey>are there a lot of varargs functions that matter in this way? <mark_weaver>tromey: I suppose we could work around the problem by never compiling Scheme code into varargs functions. <tromey>I mean, I can't really say for sure, since I'm not much of an ABI person <tromey>I'm just noting that it's reasonable to push "execution model" improvements into gcc <tromey>though of course that gives you a harder dependency <mark_weaver>it would certainly be very useful, and not only to Guile, but to many other functional programming langauge implementations. <mark_weaver>on the other hand, becoming sufficiently familiar with the GCC code base to make such changes would be a lot of work. <mark_weaver>there are other problems as well. in Scheme, continuations can be invoked multiple times, and this must be taken into account by optimizers to avoid unsafe optimizations. <tromey>my guess is actually that guile is better off with its own compiler <tromey>though that too is a hard proposition <ArneBab_>mark_weaver: I would not underestimate the cost of building a compiler… how about building a GCC frontend instead which leverages the full GCC optimization without dropping to C first? <ArneBab_>a language frontend (I hope frontend is the right word here) <ArneBab_>so GCC could produce binaries directly from scheme <ArneBab_>there is already a lot of lisp in there (IIRC GIMPLE is a lisp dialect), and this would mean that all of GCCs optimization would be available right away <nalaginrut>dunno, but I wonder if GCC backend is suit for generating efficient code of Scheme <ArneBab_>I don’t know, but I guess that it will be much more efficient than writing an own compiler - except if guile can get a EU grant like PYPY <ArneBab_>so this could be a base for building a GCC-backed compiler for guile <ArneBab_>(though that currently might require using intermediate C - I’m not sure on that) <nalaginrut>but personally, I like Guile as an independent dynamic-language compiler collection, rather than be a plugin of GCC <nalaginrut>is there any given api to convert '(#:a 1 #:b 2) ==> '((a . 1) (b . 2))? <TaylanUB>I'd certainly expect that to be called `plist->alist' if it exists, so I'd search for such a symbol. <nalaginrut>(receive (k v) (partition keyword? aa) (map (lambda (k0 v0) (cons (keyword->symbol k0) v0)) k v)) <wingo>(define plist->alist (match-lambda (() '()) ((k v . rest) (acons (keyword->symbol k) v (plist->alist rest))))) <mark_weaver>nalaginrut: your 'plist->alist' isn't quite right. keywords can be used as the values passed via a keyword argument. wingo's is correct. <mark_weaver>ArneBab_: the problem is that Scheme has a much more general control flow than any of the languages supported by GCC. The optimizers in GCC make assumptions that simply don't hold true for Scheme. <mark_weaver>civodul: do you see any reason to keep 'scm_i_tag_name' around (gc.c)? it's unused, and has been for a long time afaict. <wingo>didn't i remove it from master? <mark_weaver>tromey posted patches to guile-devel, including one to remove it. <tromey>btw one of those patches is now obsolete <civodul>mark_weaver: in 2.0 it's SCM_INTERNAL, so we can remove it <civodul>woow, it's great to have patches from you tromey <civodul>you're at the bottom of the original ChangeLog ;-) <tromey>funny, I could have sworn I had more patches than that <tromey>like I have a memory of writing a couple of patches to the code itself back in the day <add^_>Hm, what version of libgc should I use again? gc7_2e? <shanecelis>Let's say I'm using (oop goops) and I want to wrap an instance in another class that changes some behavior, but everything else I want to be handled as if my wrapper were not there. <mark_weaver>shanecelis: what does it mean to "wrap an instance in another class" ? <shanecelis>(define wrapped-object (make <wrapper> #:wrap-this object)) <shanecelis>Say object has the following method, (do-thing object) <shanecelis>I want to be able to cleanly (do-thing wrapped-object) without <wrapper> having to worry about it. <ijp>basically, you can't <ijp>dispatch is done based on class, so wrapper would need to be a subclass of the type of the object <ijp>if object can be anything, you're screwed <unknown_lamer>shanecelis: you'd need to use a metaclass and customize dispatch <shanecelis>well, not without doing anything, but without manually recreating all methods and dispatching them myself. <mark_weaver>ijp: I wouldn't be so sure. The MOP is quite powerful. <shanecelis>unknown_lamer: cool. I have no idea how to do that. <ijp>mark_weaver: when you start playing with the MOP, you are risking breaking everything <unknown_lamer>shanecelis: you could customize whatever the goops name for no-method is, and then re-try dispatch based on the wrapped object <unknown_lamer>however, I am not sure that's easy, or desirable... goops's (next-method ...), unlike CL's, doesn't let you alter the arguments... so you'd have to use the introspection mop and whatnot to find the method name and other fun things <mark_weaver>ijp: well, it's well known that you're not a fan of CLOS/GOOPS, but that doesn't warrant saying "you can't". <unknown_lamer>why not just subclass if you want to customize behavior anyway? <mark_weaver>unknown_lamer: might 'compute-applicable-methods' be a more appropriate generic to add a method to? <mark_weaver>unknown_lamer: well, all it would have to do is forward the call to 'compute-applicable-methods' on the class of the wrapped object, no? <shanecelis>Basically, I'm doing a GA, and I have a <phenotype> class. I'd like to wrap a phenotype in a <fixed-phenotype> which is a simple matter of subclassing, but I'd also like to pretend like that object is same as the initial object. <mark_weaver>it seems incorrect to me for 'compute-applicable-methods' to not include the methods of the wrapped object. <shanecelis>same as in responds to the same set of methods except those defined in <fixed-phenotype> <mark_weaver>it's not really the same object. what if you ask for the list of slots, for example? <mark_weaver>should the list of slots include the 'wrapped-object' slot? <unknown_lamer>shanecelis: I don't see why simple subclassing wouldn't work (you can always create new classes at runtime, it's one of the examples in AMOP) <shanecelis>Hmm... I may just have to rethink using this like <robot> is-a <phenotype>, and think of it more as <robot> has-a <genotype->phenotype>. Then I wouldn't have to do this nastiness. <tromey>it seems odd if there is no way to implement a proxy though <mark_weaver>it can certainly be done with the MOP, if you can decide precisely what the semantics should be. <shanecelis>unknown_lamer: Oh... wait, so you're suggesting dynamically creating <robot-1> which extends (<robot> <fixed-phenotype>) as a solution? <unknown_lamer>tromey: same way you would in another language... manually duplicating all of the methods in the interface <tromey>dynamic languages should be better than that <shanecelis>unknown_lamer: I figured I could do that by manually proliferating classes, which seemed bad, but if I could just dynamically create a class with this tacked on, hmmm... that sounds much nicer. <mark_weaver>unknown_lamer: that seems like an odd claim. I can certainly imagine cases where proxies would be useful, e.g. for representing an object on another machine. <unknown_lamer>tromey: the idea of a proxy doesn't make sense when generics are not part of classes <unknown_lamer>but then... afaict proxies are just implemented by subclassing a common parent, no? <mark_weaver>unknown_lamer: it seems to me that it would make sense for a generic to replace all the proxies in the argument list with the things they a proxying. <mark_weaver>but admittedly, things get a little messy, because you still need to occasionally do operations on the proxy itself, as opposed to the thing that it's proxying for. <shanecelis>(define (make-fixed-phenotype-class extended-phenotype-class) <shanecelis>(make-class (list <fixed-phenotype> extended-phenotype-class) '())) <shanecelis>hmmm... this might work. I like it better than going MOP crazy. <mark_weaver>at some level, the system needs to be able to distinguish a proxy from the thing its proxying. and that's where the semantics get messy if you try to make it emulate the proxied object in every respect. <ijp>in racket, the way you distinguish between a foo, and a bar impersonating a foo is that they are equal? but not eq? <mark_weaver>ijp: that works if you have a specific object in mind, but I don't see how it could work in this case, where you could have any number of proxies for any number of proxied objects. <mark_weaver>at some level, the system needs to be able to view a proxy as a proxy, so that it can extract the 'proxied-object' slot from it, and so that it knows to do the forwarding operation. <tromey>I'm curious why no-applicable-method can't be overloaded to allow this <civodul>shanecelis: you could change the class of this-object, i think <civodul>there's a class change protocol in the MOP <civodul>well, that's when changing a <class>, not when changing an instance <mark_weaver>tromey: I suspect it could be, but I'm not sure that's the best solution. <tromey>I don't know, but I'm curious if it works <mark_weaver>hmm, well, maybe not. 'no-applicable-method' is itself a generic function defined on two arguments: the generic function, and the list of arguments. I think perhaps the only way to define a new method on 'no-applicable-method' is to make a new class of generic functions. but admittedly, I'm not an expert on CLOS/GOOPS. <mark_weaver>same problem with trying to overload 'compute-applicable-methods'. <tromey>it seems less than useful to pass a list of arguments there <mark_weaver>with single-dispatch OO, there's only one object that could determine how method dispatch happens. but with multiple-dispatch OO, any number of the arguments to a generic function might be proxies, so it's a bit messier. <mark_weaver>tromey: why do you say "less than useful"? what would be a better way? <mark_weaver>now, I can see that it would certainly be possible to define a subclass of <generic>, and define a new method for 'compute-applicable-methods' (or 'no-applicable-method') for those generics. <tromey>I thought if the arguments were flattened then one could write an instance of the method to pick out the application to the proxy <tromey>perhaps I don't understand it well enough <tromey>totally probabl - but really why I'm asking <mark_weaver>tromey: well, the problem is that in general, there could be any number of arguments, and any of them (or more than one them) might be proxies. <tromey>I mean, sort of, since one could just have multi-level forwarding and use the standard techniques for method priority <add^_>Hmm, I just realized I've been compiling *master*, not stable_2_0... *add^_ forgot that he hadn't forgotten to change <civodul>at the time GOOPS was my favorite thing in Guile ;-) <ijp>I remember having a discussion with samth a year or two back where he predicted I'd end up a static typing guy <civodul>ijp: has he been proved right already? <ijp>civodul: pretty much <civodul>though i think we need both, in the same way the CRASH people write <mark_weaver>ijp: you definitely seem like a Haskell kind of guy to me :) I confess I often wonder why you bother with Scheme at all, given your inclinations. <ijp>mark_weaver: the same reason I haven't thrown out this cardigan I've had for a deacade <ijp>and the other one, lisk or whatever it was <ijp>hah, I even know the lisk guy <mark_weaver>I agree it would be nice to support optional type declarations in Guile. <davexunit>haskell people seem to think that scheme is a toy that can't do anything right. <davexunit>"no static type system? not purely functionaL? how could you possibly use such a thing!" <civodul>the Scheme community is very diverse too, from people who use it like Haskell to people who use it like C <ijp>which reminds me, do NOT look in the lalr-scm source <mark_weaver>I went through a period of *loving* Haskell, and I still admire it. However, like most other languages, it is tailored for a particular style of programming, whereas Scheme is adaptable and can accommodate just about any style of programming gracefully. <fangism>i love that scheme lends itself to creating domain-specific languages