***Soft is now known as Guest21654
***imaaminpoika is now known as FinestScottishAc
***ldgonza84 is now known as ldgonza
<ldgonza>I'm having trouble using trace, can someone point me in the right direction? <ldgonza>I'm using ice-9 debug, but I still get that "trace" is not bound <ldgonza>I can't figure out what's wrong from the manual, and I'm not being able to find better docs, or examples <ijp>well, since the module doesn't do anything, there are no examples <ijp>all it does is print out a deprecation message pointing you to (system vm trace) <ijp>for simple code tracing, you use the ",trace FOO" repl command <ijp>I don't know how to prune it, so it's not very useful to me, YMMV <ldgonza>how did you find out that ice-9 debug was deprecated? I didn't get any message <ijp>yes, I don't see it either oddly enough, but I looked in the source code <ldgonza>there, found the manual section dealing with (system vm trace), and it does make use of ,trace ***Soft is now known as Guest4225
<ijp>I'm not sure why you can't navigate by keyboard though <nalaginrut>maybe it's worth to rewrite lightening with Scheme... <Madsy>nalaginrut: Lightening? The GNU library for making JITs? <ijp>hmm, I just noticed I replied to something on the wrong channel <Madsy>Is it still updated regularly? <nalaginrut>Madsy: I don't know if it's still updating, but seems it's workable. Anyway, as a jit lib, I think it's already done, so it's reasonable if it stop to update <Madsy>Well, instruction sets are supplemented. So it's nice to have support for newer and faster instructions :) <Madsy>Also, there is always code rot <nalaginrut>Considering Guile will become AOT+JIT someday, and prefer pure Scheme implemented, I think rewrite lightning is worth, personally <Madsy>I had to build a linux system from scratch a week ago. Where the build system was so old that the makefiles weren't legal make syntax anymore <Madsy>So we ended up building it on a really old Debian box. The Debian release after Sarge or whatever it was <Madsy>No, worse. It was based on some old build system which uclinux is based on <nalaginrut>I can't compile gcc-1.35 since I've no idea how... <Madsy>The Linux-from-scratch books don't seem that bad to me. It seems to be always updated *nalaginrut stop to play LFS after he finally build LFS-6.2 successfully ***FinestScottishAc is now known as JeromeTheFrench
***JeromeTheFrench is now known as octopodes
<janneke>ERROR: In procedure source-properties: <janneke>ERROR: In procedure source-properties: Wrong type argument in position 1 (expecting non-immediate): #f <janneke>Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue. <janneke>how do i find out (not from C) if something is a (non-)immediate? <civodul>janneke: it only works on pairs, basically <janneke>civodul: i had that, before i introduced goops <janneke>but that will do; pair or instance --thanks! ***Soft- is now known as Soft
<octopodes>Hmm, say you have (+ (f) (g)) where (f) and (g) both produce a number but can generate an exception. <octopodes>Catching that exception allows you to observe the evaluation order right? <taylanub>yeah. can also do so through side-effects in f and g which are observed from each other... <octopodes>Well, that throws some wrench into the idea that exceptions are pure and referentially transparent right? <taylanub>not sure what it means for an exception to be pure <octopodes>They are pure insofar only a single bottom value exists, as soon as you can differentiate order of evaluation influences the program. <octopodes>I had a discussion here a while back about exceptions where it was claimed they don't perform side effects. <octopodes>"side effect" being a matter of semantics, it's hard to argue they are referentially transparent. <dje42>Is there a point to such discussions? Or is this just fun academic banter? <taylanub>octopodes: what exactly is or isn't referentially transparent? I'm only familiar with that term wrt. function calls. is it e.g. a call to `raise-continuable' you're worried about? <octopodes>taylanub, no if it continues it's actually fine. <taylanub>not sure if that's a correct usage of the term "referentially transparent" <octopodes>taylanub, well, surely referential transprancy is lost as soon as evaluation order matters. <taylanub>matters to what? to `+'? + is never called <octopodes>Matters to that dynamic typing doesn't exist of course <taylanub>I didn't understand your forelast sentence. <civodul>non-local exits are sometimes referred to as "control flow effects" <taylanub>octopodes: do you know of let/ec? your example should be equivalent to (let/ec return (ignore (return 'left) (return 'right))) which might be easier to reason about. is `return' referentially transparent? the question seems wrong because return doesn't .. return, heh. <octopodes>taylanub, one can argue that abondoning the current current continuation for another one is not a referentially transparent operation no. <octopodes>But often locally non transparent operations can be packed inside functions and macros that are. <octopodes>As in, the vector function often ingenerally will use vector-set! but externally is still referentially transparent <dje42>IWBN if libgc provided something other than an environment variable (GC_MARKERS) to specify the number of marker threads. <dje42>If I set it in gdb then I should really unset it after guile is initialized otherwise the value will be imposed on the inferior. unsetenv is not thread safe (it's probably ok, I can imagine some being comfortable with it). <dje42>setenv isn't thread safe either of course, but until guile is initialized gdb has no threads. <mark_weaver>is it necessary to inhibit marker threads? does libgc not block signals in its marker threads? <dje42>Plus there's a whole "threads are scary" subcommunity within gdb-land. ***octopodes is now known as ScottishAccent
<dje42>The solution for SIGCHLD is to block it before initializing Guile and then unblock it afterwards. Ideally libgc would do this though, for sure. <mark_weaver>well, that's the temporary solution anyway. I think the better longer-term solution is to patch libgc and guile to make sure that all internal threads block as many signals as possible. <mark_weaver>there's always the possibility in the future that internal threads might be spawned after initialization. <civodul>dje42: re "threads are scary": on GNU/Hurd, each C program has an additional messaging thread spawned by libc :-) <ijp>ScottishAccent: they do have side effects, but not in the sense of mutation per se <ScottishAccent>Well, mutation needndn't be a side effect, I think that distinction is useful yes. <ijp>"side effect" gets used for basically any impurity, and the relevant one here is partiality <ScottishAccent>Well, like I said, partiality can still be pure as long a sonly one single bottom value exists. <ScottishAccent>Which sort of follows rom the idea of bottom type, that nothing inhabits it. <ScottishAccent>As soon as you have multiple different inhabitants of the bottom type I have a hard time calling it one. <ijp>I think you misunderstand bottom, it inhabits every time <ScottishAccent>But that depends on how you model it, you can say that every type has the bottom value, or that every partial function's return type is a union of its "actual" type and the bottom type which has no members, or one. <ScottishAccent>Like ehh, in Idris for instance, the type system can prove totality, in which case the "bottom value", which is a pretty shady concept, is not a member of the return type of the function <ScottishAccent>Haskell's type system not being powerful enough to prove totality, essentially things like Int are always basically Int | Bottom <ijp>ScottishAccent: well, right, with a more powerful type system you can enforce/prove totality, but I'm not sure if they can have meaningful exception handling <ijp>ah, you mean only as a feature of partial types <ScottishAccent>But I'm saying that the model where there's no such thing as a "bottom value" only a bottom types makes more sense and a partial function is simply a function whose return value is a union of something can the bottom type. <ScottishAccent>Well, a partial type is a union with the bottom type, as ain a function which may not return. <ijp>maybe you're right, I haven't really thought about this <ScottishAccent>Well, the model that bottom is simply a value that is a member of every type makes sense for say Haskell because the type system there can't exclude partiality. <ScottishAccent>The type of a function tells you nothing about its totality there, any type may be partial. <ScottishAccent>None of the sort, can you record yourself saying "But she's givin' us all she's got capt'n"? <ScottishAccent>Something tells me you don't take my desire to complete my collection of finest Scottish accent as seriously as I.. <nalaginrut>like (match x ((or "aaa" "bbb") "yes") (else "no")) <davexunit>paroneayea: went really well. visited my family yesterday for my birthday dinner thing. <davexunit>my 5 year old niece demanded that I should have a pinata, so my sister bought one. haha <paroneayea>I spent most of the weekend learning deployment systems for the mediagoblin-premium-hosting thing we'll be doing eventually, but also saw Ghostbusters in a theater (they were doing a 30th anniversary screening) <ijp>nalaginrut: match should work correctly on strings, ys <paroneayea>we're most likely to use ansible I guess, but the weird combination of yaml files and jinja2 templates is just a super odd pseudo-DSL <ijp>taylanub: no, that would be less useful <taylanub>yeah. I see `case' as an analogue to `switch' <paroneayea>I'm getting verrry tempted to toss together a DSL in either guile or hy that just wraps some deployment commands. ("How hard could it be?" he said, not forebodingly) *davexunit watches paroneayea go down a human-sized rabbit hole <ScottishAccent>Surely with match there are just some things that don't match though. <ijp>(define (f x) (match x ["foo" 'yah] [_ 'nah])) (f (string #\\f #\\o #\\o)) $2 = yah <davexunit>yeah, records can be matched and its awesome. <ijp>this gets used quite a bit in e.g. the cps compiler *nalaginrut continue to work last 5 minutes before sleep... <nalaginrut>before I go to sleep, I want to confirm that 'case' is not safe for strings, right? because it uses eqv? <janneke>how can i use curried definitions together with goops? <janneke>i'm using a methods that return an untyped lambda now :-( <ijp>an interesting question, but I suspect there is no goops lambda <ijp>unless that's what `method' is <ijp>you'd need to write your own currying macro though <ijp>which is pretty straightforward <mark_weaver>well, I don't think that would have the desired semantics <ijp>I'm not even sure what the desired semantics would be <mark_weaver>well, suppose you want to add two methods that both accept the same type for the first argument, but different types for the later arguments. <mark_weaver>these two methods are declared in different top-level definitions, in different modules. <mark_weaver>and somehow this needs to get merged into a single method that takes just the first argument, and returns a generic function that matches based the later arguments. <mark_weaver>and that generic function needs to be extensible in practice, so that new methods added later will result in the needed changes being made to that generic function. <mark_weaver>but I guess for currying, you also need this generic function to somehow reference the first curried argument as a free variable. <mark_weaver>so you'd of course create a new generic function each time the first argument of the curried function was passed, but all of these fresh functions should, I think, reference a single global method table. <mark_weaver>a global method table for handling the arguments after the first argument of the original curried generic functoin. <ijp>I see a lot of headaches in your future <mark_weaver>it's a nice idea, and perhaps it could be done, but it's not trivial. <ijp>how does goops handle rest args anyway, I would imagine (define-method (foo (b <bar>) (c <baz>)) ...) vs (define-method (foo (b <bar>) . rest) ...) is nontrivial <mark_weaver>I would guess that rest arguments, always untyped, should be considered less specific than any method that requires more arguments, but I don't know. <mark_weaver>and also less specific than methods that require any fixed number of arguments. <mark_weaver>but my knowledge of GOOPS is extremely limited, I confess. <mark_weaver>I think I have some idea how curried generic functions could be implemented. <daviid>for info: 28.1.6.4. Congruent Lambda-Lists for All Methods of a Generic Function <mark_weaver>basically, each curried generic function would keep a mutable table of its auxillary generic functions. <mark_weaver>the table would be keyed on method-argument-type-specifiers (or whatever they're called), and for each such first-argument-type would have a generic function that handles the remaining arguments. <mark_weaver>when adding a new method to a curried generic function, this tables would have to be consulted to make additions to the appropriate auxillary generic functions. <mark_weaver>e.g. if there's already a method to handle ((foo (a <bar>)) (b <bar>)), then adding a method ((foo (a <bar>)) (b <baz>)) needs to add a method to the generic-function-that-handles-the-second-argument-when-the-first-argument-was-a-<bar> <ijp>the obvious way I can think of is to represent a curried generic as a curried function that calls a generic (which you extend) <mark_weaver>and then the other complication is the free variables. they'd have to passed later. <mark_weaver>so the result of calling the auxillary methods would actually be to return a procedure that accepts the earlier arguments and then does what the curried method should do. <ijp>but I think this is problematic with variable arities <ijp>(define-method ((foo (b <bar>)) (c <baz>)) ...) => (define ((foo bar) baz) (foo* bar baz)) (define-method (foo* (b <bar>) (c <baz>)) ...) <ijp>another issue is that that would defer type errors <mark_weaver>daviid: oh, interesting, thanks. am I reading that correctly, that in CLOS, all methods for a generic functions must accept the same number of required arguments, same number of optional arguments, if one has rest or key, all have to, etc? ***fangism-hongry is now known as fangism
<daviid>mark_weaver: yes for the first, i don't know for the second <ijp>no, goops doesn't have that restriction <daviid>goops unfortunatle does not follow the spec, it should, fully, imo <mark_weaver>well, it's can't possibly fully follow a spec for something designed for common lisp. <daviid>clos is a language, not a toy to play with. imo, goops should follow that <daviid>mark_weaver: i desagree, goops does not have to be scemy or lispy or haslekky, it has to be clos <ijp>that's a nonsensical statement <daviid>it that requires options [the module system for example has been discussed here quite a lot...] then it should proviede these options <ijp>you can't rip clos out of cl and have it be useful on its own <mark_weaver>well, for example, the differences in how common lisp packages handle symbols vs scheme modules is quite significant, and that requires adjustments. <daviid>mark_weaver: yes, we've discussed that already. we already have all that is needed except this re-export [extremlly annoying] requirement put upon the user where is should be [at least as an option] upon the implementation <daviid>and there is a terrible bug on g/s/a propagation which forces us to redefine those for subclasses <mark_weaver>in common lisp, you can lookup a variable solely from the symbol, because each package has a different name->symbol mapping. <ijp>daviid: have you tried implementing this yourself? <ijp>I can't promise we'd accept it, but unless mark_weaver does it, that's the only way this change is happening <ijp>civodul and wingo are busy, I'm against it, and I don't think you've even brought this up on the mailing list, have you? <daviid>mark_weaver: let's be practicle: goops is almost there, some bugs to be solbed but ok... through merge generics, we have what we need, the only lack is this re-export stuff <mark_weaver>I'm not entirely sure I know what's being discussed here (I'm not sure what g/s/a propogation is off-hand). <daviid>getter/setter/accessors, especially setters, are not doing their job for subclasses, do you remember the bug reported we've been playing with [the quyantum mecanic slot state.. <mark_weaver>I've explained before why the merge-generics solution is not adequate and has lots of problems. <daviid>it is adequate, there should only be 1 generic functions, that is the spec and that is what experienced clos prog who had to switch to gule :) expect <mark_weaver>first of all, it means that each module ends up with a generic function that only handles the classes that it specifically imported modules from. <daviid>mark_weaver: save your and my time here, I don't want to talk about the spec, it is perfect <daviid>i mean the clos spec of course :) <ijp>I know what you meant <daviid>all i am asking is a module option for not to have to re-export <mark_weaver>I'm talking about a proposed merge-generics solution that doesn't do anything remotely like what clos does. <daviid>and debug this terrible problem i've just mentioned <mark_weaver>correct me if I'm wrong, but in CLOS, there is just one global generic function object for each name, and all methods are added to that one. is that right? <mark_weaver>daviid, I genuinely would like to help you, and I agree that things are suboptimal, but I can't help unless you can help outline a specific way to fix the problem that doesn't conflict with guile's other requirements. <daviid>mark_weaver: yes, but from a practicle point of view, merge-generics gives us what we need, ' generic function per module [with its imports...] <mark_weaver>when a module calls a generic function, it should reasonably expect that methods could be invoked that the calling module knows nothing about. merge-generics does not do that. <daviid>sorry i dont understand what you are trying to tell me here <daviid>there should be 1 generic fuvtion, users must _not_ create, because there should be one only and it is a bug to redefine a generic function <daviid>the generic function is a container nothing more nothing less <mark_weaver>clos is based on the idea that for each generic function, let's say "size", there is just one global generic function object, and everyone uses that one and all methods are added to that one. <mark_weaver>so anyone, anywhere, who calls the 'size' GF, will have available very method in the entire system. <daviid>yes. on guile we do that by merging, which is fine <mark_weaver>but the merge-generics solution does not accomplish that. <daviid>i think you mistaking that packages exists in cl too, one can use a generic function if it import the package that defines it <mark_weaver>here, suppose you have one module (foo bar) that defines class <bar> and ends up creating a 'size' accessor, but relies on GOOPS to auto-create the generic, so it ends up a generic function specific to the (foo bar) module, that only knows how to handle <bar> <mark_weaver>and how you have another module (foo baz) that defines class <baz> and defines its own 'size' method. again, goops automatically creates a new generic function, and this one only knows how to handle <baz> <daviid>yes, then you import both and previously specified merge- ... so its fine[ <mark_weaver>now you have a module that imports (foo baz) and calls the 'size' generic function on some object passed to it from a user. <mark_weaver>but my point is, merge generics gives you generics that only work on the classes that you imported from. <janneke>wow, ijp mark_weaver what a viewpoints! :-) <mark_weaver>not for any classes defined elsewhere in the system. <mark_weaver>and that's fundamentally broken, and not at all how CLOS works. <daviid>it is not broken, it is what you want <daviid>methods are added as modules that defines them are imported <mark_weaver>listen, suppose that's how it works for numbers. so I write a module that accepts a list of numbers from you and gives back their sum. <mark_weaver>now you install a new number type, and gives me some of those numbers. my code can't add them because I didn't import the module that defined that particular type of number. <mark_weaver>well, in that case it would work because there _is_ a single module that exports the '+' generic function, and everyone uses that same one (within reason) <daviid>mark_weaver: from guile co maintainers, if i am not mistaken, the only one who knows goops implementation is wingo right? <daviid>mark_weaver: yes, the + is the _perfect example for you to understand that it _is what we want for _all generic functions and it _is_ the proof that it _can be implemented in scheme as well <mark_weaver>I agree, we want all generic functions to be exported from a single module. <daviid>wingo has implemented a trick to do that in guile-gnome <daviid>now, we have a serious problem with this export re-export problem <mark_weaver>the problem is that you are allowing goops to automatically create generic functions when you define methods, and you are ending up with multiple different generic functions with the same name, each which can only handle some subset of methods. <mark_weaver>what I think you _really_ want is a single global namespace for generic function names, e.g. no modules, 'size' refers to the same generic function no matter the module system. <daviid>mark_weaver: that is the spec, it should create the generic function, but then it should keep track of that, like it does for + <daviid>guile should keep track for our generics like it does for + <daviid>mark_weaver: yes to the last sentence <taylanub>daviid: I think you just contradicted yourself; previously you said it's fine that there exist separate generics which hold different subsets of methods? <daviid>there should only be 1 generic funtion, it must be created automatically, it is an error to redefine it, methods should be added as they are defined/imported ... <mark_weaver>the problem is, that is fundamentally incompatible with our module system. when we see (size x), we cannot know if that's calling a generic function, so we can't apply different rules and look up in some global namespace. <daviid>taylanub: several generics is a guile implementation mistake i agreed to live with and i m always merging <mark_weaver>we need to look up 'size' like any other variable before we can even hope to know whether it is a generic function call. <mark_weaver>we don't have that information until run time, so we can't apply different scoping rules in that case. <mark_weaver>now, we if had some fundamentally different syntax for calls to generic functions, then we could give generic functions a global name space. <mark_weaver>well, '+' is in the default guile namespace, so modules don't have to import it, it's just there. <daviid>we need another default namespace <daviid>by the way anyone knows why some goops bit are implemented in C ? <mark_weaver>daviid: the technique exists to add bindings to the default global namespace, and to bind some of them (such a +) to generic functions, yes. but we cannot do that for every symbol. <daviid>it defines all gnome generics in 1 module independently from which module it's done [maybe i'm not clear here sorry] <mark_weaver>that sounds like what I've been suggesting all along: each generic function is defined and exported from just one module. <mark_weaver>that ensures that everyone is using the same global generic function, with its associated method table. <daviid>mark_weaver: here above, the 1st sentence: the generic function is defined the first time goops sees a method, or by the user if he wants [but this is _not_ a good idea], it lands in 1 module, then other methods are added ... it is _not_ defined from 1 module only <taylanub>It might be fine to have same-named generics with different methods. Java-style-OOP analogy: classes Foo and Bar have method quux. I import Foo only, but something gives me a Bar instance; I can't call quux on it because I can't tell the compiler it's a Bar (since I haven't imported that class). this compile-time error in this pseudo-Java corresponds to a run-time error in GOOPS because calling <taylanub>quux on the Bar object couldn't find Bar's quux. <daviid>java is _not_ a true oop language, do not inspire yourself from there <ijp`>anything can be oop if you don't define your terms <taylanub>I think the analogy is sound. Java has single-dispatch only; doesn't matter here. <daviid>ijp there are articles about that some published.. i just don't want to loose too much of my time and my concern is to talk about getting goops closer to clos, while respecting the module system guile promote <mark_weaver>daviid: ah, so if you define a class that implicitly defines accessor generics in module (foo bar), somehow the generics will get added to some single special module? and then all users of guile-gnome can just import that one module and get all the generics. do I understand correctly? <ijp>if you want one generic, define-generic *once*, import that package, and define-method that <daviid>mark_weaver: let me read twice :) <ijp>it requires no changes to the module system, or goops, and respects both traditions <taylanub>that should work equally well with auto-generating the generic and merging any generics on import <daviid>taylanub: yes it only works if the user does _not_ create the generic himself and laways use merge... <daviid>mark_weaver: almost. following guile's module idea, which i do like by the way, let me rephrase <daviid>yes with first part, until to some special module. then when a user imports a module that define method(s) he actually imports the generic from that special module [that may be hidden to him]. computa applicable methods always uses that generic <mark_weaver>again, the problem is that you must be able to apply a generic function to types that you didn't anticipate when you wrote your code. <mark_weaver>and that means that you can't use a generic that includes only methods from modules that you imported. <daviid>applicable methods will always work fine <ijp>you can design a system like that, but goops is not it <taylanub>those types will either be defined by a module that imports yours, or imports a module that you yourself imported. in practice, you do end up sharing the generic anyway <daviid>user import glib because he wants to use get/set methods <daviid>then he adds a class and defined his own get set methods ***ScottishAccent is now known as Max_Gentlemen
<daviid>and so on ... you can't possibly create a bug situation by adding methods to a generic fucntion, and as a user, i imported glib and use the get/set methods on gnome instances, it does not matter, like the guile's internal + example, that there exist other applicable methods <dsmith-work>So what would happen in CLOS if one package/module defined a function, and a different one defined a GF with the same name? <mark_weaver>one issue is that it should be possible for two libraries, developed independently, to each make use of generic functions with the same name but with incompatible calling conventions. <ijp>different packages mean different names, no? <mark_weaver>and in these cases, they really should be two different generic functions, each with their own method table. <daviid>mark_weaver: the draw example... actually the only problem here is/are class names, not generics anymore <taylanub>oh, so that rules out auto-merging of generics on import? <dsmith-work>ijp: I think so, but when you import/use/whatever you would get some kind of a conflit? <daviid>mark_weaver: but that is _not_ specific to goops anymore <daviid>actually it will bug, now, in guile, if a user redefines a class that + handles internally [for eaample] <daviid>taylanub: the same way you would redefine a procedure usihng the same name in diffent modules and import [without prefix] ... <mark_weaver>the fundamental issue here is that because merging of generics with the same name is sometimes wanted and sometimes not, we must somehow specify which generic function object in the system you want to add methods to, and its name is not enough. <mark_weaver>we again come back to the notion that each generic function should be explicitly defined and exported from a single module, and every module that wishes to add methods to GFs should first import the explicitly defined generic functions. <daviid>mark_weaver: yes that would be ideal of course. then i thought about that and how about an option from the module system? the same way we have an option for merging, we could live with one more option ... <mark_weaver>I will grant you that it's not as convenient as I'd like, but I still have yet to hear of any other acceptable solution. <daviid>mark_weaver: right now, my idea is to add a specific export option [to the module systtem] for getters setters accessors and other user defined methods that a user, me :), can use and it then export the hidden central generic function <daviid>and if not, the actuall and could still be the default, it export the newlly created generic with only applicable methods from the module it is exported <mark_weaver>again, the regime of creating isolated generic functions in each module and merging together only the ones from modules you import is *incorrect* <daviid>mark_weaver: what is incorrect is notr being able to simulate clos using goops <mark_weaver>when you call a generic function, it must be able to access methods that handle types you didn't know about before hand. <daviid>practically speaking, we are almost there <daviid>mark_weaver: not sure i undertand what you think in your last sentence <daviid>when a user imports a module, he does so with the idea to use methods upon object instances for which he knows there is an applicable method <mark_weaver>suppose I write a graphics system, and I have this <graphical-object> type with a 'draw' method. now I have a procedure that takes a list of graphic objects and draw each one in turn. <mark_weaver>this procedure is in some core module (graphics renderer) <daviid>define-class <clus-apple> (<clutter-actor>) <daviid> (orientation #:accessor !orientation #:init-keyword #:orientation #:init-value *clus-default-orientation*) <daviid> (gravity #:accessor !gravity #:init-keyword #:gravity #:init-value *clus-default-gravity*)) <mark_weaver>in this case, 'draw' really will be defined in just one module, and imported in every module that might add methods to it. <taylanub>re. "when you call a generic function, it must be able to access methods that handle types you didn't know about before hand": those types will be defined by a module that imports either yours, or one that you also had imported, so in practice you end up sharing the generic if you auto-merge. if an object really comes from a "totally different world" then IMO it's fine to raise a type error (the <taylanub>Java-OOP analogy being the static type error) <taylanub>mark_weaver: if there are specific arguments *against* auto-merging (you mentioned something about different calling conventions above; I don't know what that means) then I understand the concern, but otherwise auto-merging seems to work fine <daviid>java is _not_ a good reference, it is obsolate by def, even it's been defined far later... <taylanub>daviid: I really think the analogy holds fine here, no matter how different/bad Java is <daviid>mark_weaver: draw generic will be imported only by modules that import the original def where draw is defined, no? <daviid>taylanub: read the clos spec, there is no need for analogy, it is far better then java <mark_weaver>when generic functions draw-1 and draw-2 are merged together into draw-12, what happens if methods are later added to draw-1 or draw-2? <taylanub>if they import any of draw-1, draw-2, or draw-12, yes. <mark_weaver>you answered awfully quickly, I wonder if you really know. <daviid>mark_weaver: the generic is not updated, methods are added and it means that there are more applicable methods, but whoi used draw upon object of class 'draw'2' still uses the applicable method that the system [goops] gives him ... <taylanub>well, I don't see the difference between "generic function" and "method", other than the former being a name carrying a collection of the latter. so yes, I would expect further "draw" methods to get added to the same generic function <mark_weaver>I mean, suppose (foo bar) and (foo baz) both implicitly define a 'draw' generic function, each one only knowing how to deal with its own type, and then you import both of those modules into (guile-user), so the 'draw' in guile-user can handle both types. now suppose you add a new method to the generic function in (foo bar). will the merged generic-function in (guile-user) be automatically updated to include the new method? <daviid>taylanub: how many lines of clos and/or goops code do have? <daviid>mark_weaver: there is a problem in your quiz, if i may say so :) <mark_weaver>'+' is a generic function. it includes a table of methods. each method handles '+' for only certain types of arguments. <mark_weaver>the distinction between generic function and method is crucial to understanding CLOS or GOOPS. <daviid>mark_weaver: agreed with the + sentence here above, we've said that before. i want to understand and answer the draw related quiz <mark_weaver>the 'draw' example doesn't serve me, because it is a case where 'draw' really will be defined and exported from just one module, and all other modules that want to add a method will import from that one module. *civodul would find it easier to have this conversation by email :-) <daviid>ok, let's try to find something that express your concern then <daviid>just what it is impossible to handle by email *civodul hides, goes back hacking ;-) <daviid>civodul: let me talk to mark yes, please :) <mark_weaver>well, the 'draw' example is also one where this merging of generics is not needed. <taylanub>mark_weaver: the way I thought it should work, importing (foo bar) and (foo baz) from (guile-user) results in the (foo bar) and (foo baz) generics being merged into one, which is then found in all three modules, and one can add methods to it from anywhere <mark_weaver>everyone is going to be using the same generic function, already. <ijp>this conversation has been going on for an hour <mark_weaver>daviid: so I guess it would help to hear an example from you where merging of generics is really helpful. <ijp>I'm not particularly convinced it has really advanced in that time <daviid>mark_weaver: glib get/set is a good example <ijp>I'm not asking you to stop <mark_weaver>is merging needed for glib get/set? are glib get/set not defined and exported from a single module? <mark_weaver>actually, I'd also prefer to move this discussion to email, if you want to continue it. I'd rather work on some other things. <taylanub>mark_weaver: just a last question .. I'm worried that I might be just adding noise to the discussion because I'm missing some fundamental insight; is what I suggested somehow wrong? shouldn't the generics from the two modules be merged to be the same one in become available in that form in both modules (and the one importing the two modules)? <daviid>mark_weaver: merge works fine, it is a trick but it works fine. right now we need 2 things: [1] a #:gexport [for example] that does the right thing, which adding g/s/a/m to the generic if it exists [adding, not hidding which is what irt does now] and [2] to debug the bug we talked about <mark_weaver>that's a novel idea, that any importing module can effectively mutate the generics in the modules they import. <taylanub>daviid: BTW sorry for dodging your question earlier; I've in fact never used either CLOS nor GOOPS. I had the feeling that my understanding of them is nevertheless enough to take part in the discussion; if that was wrong I'm really sorry <mark_weaver>I'm sorry, I don't understand what you're proposing for #:gexport, and I don't know what bug you're referring to. <taylanub>(I'll need to look into how merge-generics really works; I assumed the whole time that it works like what I described above) <daviid>taylanub: no problem, but you don't catch experience reading, and knowledge is experience <daviid>the description the user is only the visible part of the iceberg, it has dramatic side effect upon slot states if you change the #:allocation and/or if you define setters at parent class level <daviid>my problem with #:export is that I don't want to have to know wether an imporeted module already defined a generic [which forces me to use #re-export, I do want the system to calculate that for me and add g/s/a/m ... [see the sentence above] <daviid>so my suggestion for a specific module keyword to handle my wish as an option, #:gexcport [for goops export, but the name is a shoot, i d'ont mind ] <mark_weaver>taylanub: GOOPS doesn't work as you thought. when generics are merged, fresh new generics are made for the importing module, and the generics of the importing modules are unchanged. see http://paste.lisp.org/+32UI <mark_weaver>it does appear that the merged generics get auto-updated when methods are added to the original generics. <mark_weaver>daviid: ah yes, there is indeed a bug there. I remember investigating what CL does, but I don't remember the answer. <mark_weaver>but in any case, it's not obvious to me how to fix it. my knowledge of GOOPS is not sufficiently deep. <daviid>mark_weaver: i am concerned indeed that no guilers is an expert, if i may say do, except wingo, and nobody can debug goops anymore <taylanub>if you think my idea of merging generics in that other way is worth something, I can post it to the ML for the sake of recording it... <daviid>merging works fine i already said, the problem is with export and this bug we are talking about <mark_weaver>regarding having to choose between #:export and #:re-export, that's a guile-specific thing. interestingly, if you use r6rs library syntax, you don't have to distinguish exports from re-exports. <Max_Gentlemen>mark_weaver, , what's the rationale at keywords in syntax anyawy. <daviid>how difficult would it br to implement that for generics ? <daviid>not having to choose betweenexport re-export for goops g/s/a/m <mark_weaver>an export form that works regardless of whether the binding was imported or defined locally? <daviid>clutter defines get-orientation.. i do to, in 1 module of mine, then #:export get-orientation subsequently, if i import my module, and use get-orientaton on a core clutter class instance, it raise a bug <daviid>even if i have merge-generics as a global option, export will export the newlly created generic [it seems goops always create one, even when merge is a global option, the module system seems 1st to create a generix, then sorts things out [trying to] <daviid>that newlly created generic only has 1 applicable method <daviid>if i use #:re-export, it will do the right thing <daviid>i would like #:export to behave like #:re-export, or adding a new module option that does so, hence my suggestion for #:gexport <mark_weaver>I would be okay with making #:export automatically do the equivalent of #:re-export for imported bindings. <mark_weaver>both R6RS and R7RS allow imported bindings to be re-exported without treating them specially. <mark_weaver>i.e. they have only 'export', no separate 're-export'. <daviid>to me the actual behavior of #export dealing with g/s/a/m is a bug <mark_weaver>well, for better or worse, the distinction between #:export and #:re-export was clearly intentional. #:export was designed to raise an error unless the bindings were made in the exporting module. <mark_weaver>so I'm not sure the word 'bug' fits, but I agree that it's needlessly strict. <daviid>ok, let's say it needs special treatment for goops then, i can live with that *mark_weaver goes afk for a while... ***Cork is now known as Guest9900
***Guest9900 is now known as Cork