IRC channel logs


back to list of logs

***fangism1 is now known as fangism
<nalaginrut>morning guilers~
*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.
<mark_weaver>not yet been compiled, that is.
<nalaginrut>IIRC there're three compilers in Guile
<mark_weaver>there are two interpreters and a compiler
<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.
<tromey>aha, ok
<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.
<mark_weaver>well, to do it efficiently anyway.
<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
<tromey>is it really new or something?
<ijp>we've had it for a while, at least a year
<ijp>maybe nearer two
<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>first it leverages GNU-ness
<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.
<mark_weaver>b4283: can you be more specific?
<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.
<b4283>thank you
<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.
<mark_weaver>the caller-pops-args is really the main problem.
<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
<mark_weaver>I think that's probably true.
<ArneBab_>mark_weaver: TCO actually gets disabled in debug builds, which could make the code un-debuggable: - though GCC 4.8 with `-Og -foptimize-sibling-calls` would help there. Since they already do that, maybe they are open to improvements to that.
<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?
<nalaginrut>frontend of Scheme?
<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
<nalaginrut>I mean binary code
<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_>also GCC got an experimental jit extension:
<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)
<ArneBab_>notes to that:;a=blob;f=gcc/jit/notes.txt;h=2c225ce092ccfeaa2df7bfdd79a29eec2227ceee;hb=refs/heads/dmalcolm/jit
<ArneBab_>this could be a starting point:
<nalaginrut>IIRC, JIT should be started after RTL finished
<nalaginrut>but personally, I like Guile as an independent dynamic-language compiler collection, rather than be a plugin of GCC
<nalaginrut>heya wingo
<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.
<wingo>there is no such thing.
<nalaginrut>(receive (k v) (partition keyword? aa) (map (lambda (k0 v0) (cons (keyword->symbol k0) v0)) k v))
<nalaginrut>OK, I wrote my own
<nalaginrut>TaylanUB: thanks for the name
<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?
<wingo>maybe i forgot to do so
<mark_weaver>in master, it's declared 'static', but still there.
<mark_weaver>tromey posted patches to guile-devel, including one to remove it.
<mark_weaver>going afk for a while...
<tromey>btw one of those patches is now obsolete
<tromey>the .texi one
<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 ;-)
<civodul>one of the founding fathers :-)
<tromey>hah, hardly
<tromey>funny, I could have sworn I had more patches than that
<tromey>no biggie
<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?
<add^_>Or maybe gc7_4_0 ?
<mark_weaver>sneek: gc?
<mark_weaver>sneek: boehm-gc?
<add^_>sneek: libgc?
<sneek>From what I understand, libgc is
<add^_>ah, d
<add^_>ok thanks mark_weaver :-)
<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.
<add^_>sneek: botsnack
<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
<mark_weaver>this sounds like a question for unknown_lamer.
<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.
<unknown_lamer>subclas <class> of course!
<ijp>mark_weaver: when you start playing with the MOP, you are risking breaking everything
<mark_weaver>shanecelis: why do you want to do this?
<unknown_lamer>shanecelis: you could customize whatever the goops name for no-method is, and then re-try dispatch based on the wrapped object
<shanecelis>unknown_lamer: Yes, that sounds exactly right.
<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?
<shanecelis>It's a little hard to explain, but the code is rather simple.
<unknown_lamer>compute-applicable-methods is pretty major mop surgery
<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?
<unknown_lamer>mark_weaver: there are ordering issues
<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.
<unknown_lamer>shanecelis: define sameness ...
<shanecelis>same as in responds to the same set of methods except those defined in <fixed-phenotype>
<ijp>a proxy
<mark_weaver>this seems like kind of a mess to me.
<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?
<mark_weaver>what if you apply 'is-a?' to it, or 'class-of' ?
<unknown_lamer>problem one: design patterns
<ijp>not really
<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
<unknown_lamer>you don't need proxies in the CLOS world
<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>what exactly are you forwarding *to*
<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>s/they a/they are/
<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>as crazy as it may seem ;-)
<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.
<civodul>mark_weaver: i think <generic> cannot be usefully sub-classed:
<tromey>yes, I see
<mark_weaver>civodul: ah, thanks for the link.
<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^_ sighs
<add^_>Nevermind, yay
*add^_ forgot that he hadn't forgotten to change
<civodul>mark_weaver: also:
<civodul>at the time GOOPS was my favorite thing in Guile ;-)
<mark_weaver>wow, and you used mutt too. how time changes us :)
<mark_weaver>(I also used to use mutt)
<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>mark_weaver: see! :-)
<civodul>good old times
<civodul>ijp: has he been proved right already?
<civodul>i very much buy Typed Racket
<ijp>civodul: pretty much
<civodul>though i think we need both, in the same way the CRASH people write
<add^_>ijp: was it haskell? ;-)
<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>it's comfortable
<mark_weaver>ijp: have you heard of Liskell?
<ijp>and the other one, lisk or whatever it was
<mark_weaver>ah, I hadn't heard of the other one.
<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>or maybe just the loud people think that.
<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.
<mark_weaver>(including ones that haven't yet been invented)
<fangism>i love that scheme lends itself to creating domain-specific languages