* 1.5.6: (bound? ) missing from optargs.scm @ 2002-03-28 6:30 Steve Tell 2002-03-28 8:52 ` Thien-Thi Nguyen 0 siblings, 1 reply; 12+ messages in thread From: Steve Tell @ 2002-03-28 6:30 UTC (permalink / raw) The bound? macro appears to be missing from optargs.scm in guile-1.5.6 and 1.5.4, yet the documentation still lists it. (section 10.2 along with define* and lambda*) Is this an oversight? Or what is the proper way to determine if a variable associated with an optional-keyword has been set? This may be the last thing standing between me and a gwave release that supports guile-1.3.4, 1.4, and 1.5.6. Steve -- Steve Tell tell@telltronics.org _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-28 6:30 1.5.6: (bound? ) missing from optargs.scm Steve Tell @ 2002-03-28 8:52 ` Thien-Thi Nguyen 2002-03-28 23:32 ` Thien-Thi Nguyen 0 siblings, 1 reply; 12+ messages in thread From: Thien-Thi Nguyen @ 2002-03-28 8:52 UTC (permalink / raw) Cc: guile-user From: Steve Tell <tell@telltronics.org> Date: Thu, 28 Mar 2002 01:30:57 -0500 (EST) The bound? macro appears to be missing from optargs.scm in guile-1.5.6 and 1.5.4, yet the documentation still lists it. (section 10.2 along with define* and lambda*) doc bug. This may be the last thing standing between me and a gwave release that supports guile-1.3.4, 1.4, and 1.5.6. drat we need to change things more faster! thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-28 8:52 ` Thien-Thi Nguyen @ 2002-03-28 23:32 ` Thien-Thi Nguyen 2002-03-29 6:40 ` Steve Tell 2002-03-31 22:59 ` Marius Vollmer 0 siblings, 2 replies; 12+ messages in thread From: Thien-Thi Nguyen @ 2002-03-28 23:32 UTC (permalink / raw) Cc: guile-user From: Thien-Thi Nguyen <ttn@giblet.glug.org> Date: Thu, 28 Mar 2002 00:52:12 -0800 doc bug. sorry, that was a glib answer. here is the relevant change log excerpt: 2001-05-10 Marius Vollmer <mvo@zagadka.ping.de> * optargs.scm (bound?): Removed. We should not play games with the magical undefined value. i don't particularly understand what kinds of games are no longer being played, nor what is the suggested way to achieve prior functionality. "doc bug" means some kind of blurb explaining these things is due in NEWS. thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-28 23:32 ` Thien-Thi Nguyen @ 2002-03-29 6:40 ` Steve Tell 2002-03-29 7:44 ` Thien-Thi Nguyen 2002-03-31 22:59 ` Marius Vollmer 1 sibling, 1 reply; 12+ messages in thread From: Steve Tell @ 2002-03-29 6:40 UTC (permalink / raw) Cc: guile-user On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote: > 2001-05-10 Marius Vollmer <mvo@zagadka.ping.de> > > * optargs.scm (bound?): Removed. We should not play games with > the magical undefined value. > > i don't particularly understand what kinds of games are no longer being > played, nor what is the suggested way to achieve prior functionality. > "doc bug" means some kind of blurb explaining these things is due in > NEWS. That helps a little. After a little thought I found an obvious workaround, using the default-value facility. That brings up the question: with this change, when will it ever be useful to _not_ provide a default value for a keyword or optional argument to a procedure built with lambda*? I suppose I can see how a "magical undefined value" could be a bit too much like perl's "undef" for the purists, but this does make lambda*/define* less useful IMHO. Anyway, I am now successfuly building on 1.4 and 1.5.6, with 1.3.4 testing still remaining. I feel like I have to support 1.3.4 until more of the major linux distributions start shipping with 1.4 or later. Steve -- Steve Tell tell@telltronics.org _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-29 6:40 ` Steve Tell @ 2002-03-29 7:44 ` Thien-Thi Nguyen 2002-03-30 2:26 ` Steve Tell 0 siblings, 1 reply; 12+ messages in thread From: Thien-Thi Nguyen @ 2002-03-29 7:44 UTC (permalink / raw) Cc: guile-user From: Steve Tell <tell@telltronics.org> Date: Fri, 29 Mar 2002 01:40:57 -0500 (EST) [removing bound? makes lambda*/define* less useful] this change breaks code that relies on def/undef as "valid bit". programs that model and/or use such communication channels (e.g., hardware simulators) now need to implement that protocol. if the program already uses #f (the "obvious logical" fix) now it needs to additionally define "my-undef". otherwise it can use #f. THUD author seethes inside (wtf! what a PITA), but i think i can see how this change supports encapsulation, and so "re-layering" of the API using some other out-of-band object is possible. (we can bring `bound?' back. we just need to finish this iso-API change in the right way, or justify in NEWS the new API.) wrt other woes, when i took guile-snarf off of noinst_ i did not take advantage of the dist-hook to modify already-distributed guile-snarf to emit warnings when run, even though i thought about it. my bad. the story is that what we discussed and i implemented, mvo munged so that SCM_MAGIC_SNARFER is now exposed/required/forgotten/fubared and documented. from no design to bad design, IMO. Anyway, I am now successfuly building on 1.4 and 1.5.6, with 1.3.4 testing still remaining. I feel like I have to support 1.3.4 until more of the major linux distributions start shipping with 1.4 or later. some upgrade policies have proven difficult to foresee by guile maintainers. maybe someone will fork guile and merge it w/ chicken. (this is how you trick distributors into upgrading. ;-) actually, this reminds me i need to get 1.4.1 out. thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-29 7:44 ` Thien-Thi Nguyen @ 2002-03-30 2:26 ` Steve Tell 2002-03-30 4:42 ` Thien-Thi Nguyen 2002-03-31 22:46 ` Marius Vollmer 0 siblings, 2 replies; 12+ messages in thread From: Steve Tell @ 2002-03-30 2:26 UTC (permalink / raw) Cc: guile-user On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote: > using some other out-of-band object is possible. (we can bring `bound?' > back. we just need to finish this iso-API change in the right way, or > justify in NEWS the new API.) So, might it be back for 1.6? I've got some other code that uses optargs and bound. Maybe I'll just leave that on 1.4 and wait and see. OTOH, I'd like to be able to play with goops. > wrt other woes, when i took guile-snarf off of noinst_ i did not take > advantage of the dist-hook to modify already-distributed guile-snarf to > emit warnings when run, even though i thought about it. my bad. I'm glad you didn't - that would be rather antisocial (cf. discussion on peaceful coexistance of multiple versions) > the story is that what we discussed and i implemented, mvo munged so > that SCM_MAGIC_SNARFER is now exposed/required/forgotten/fubared and > documented. from no design to bad design, IMO. Curious, what would you do differently if redesigning? Now that its official that every application has to implement its own snarfing system (or go back to manual construction of the init functions), there's plenty of room for experimentation with alternate mechanisms. It actually didn't take very much effort to disentangle my code from its mismash of snarfing macros (a mix of 1.4 and stuff borrowed from the late scwm), so I'm not annoyed. I would like to get back to coding new stuff of my own and off of compatibility-testing though. > some upgrade policies have proven difficult to foresee by guile > maintainers. maybe someone will fork guile and merge it w/ chicken. > (this is how you trick distributors into upgrading. ;-) I get the sense that one only gets to break binary compatibility every few years, so there's a strong need to make it count when it does become necessary. Some day soon, one supposes that for example RedHat will decide whether its 1.4[.1] or 1.6 that goes into their 8.x series. Presumably other distributor make the same call on their own schedules. I hope I'm helping make 1.6 more likely to be what gets widespread distribution for two years after that by porting to and testing the 1.5.x ones and asking all these questions. Steve _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-30 2:26 ` Steve Tell @ 2002-03-30 4:42 ` Thien-Thi Nguyen 2002-03-31 22:06 ` Marius Vollmer 2002-03-31 22:46 ` Marius Vollmer 1 sibling, 1 reply; 12+ messages in thread From: Thien-Thi Nguyen @ 2002-03-30 4:42 UTC (permalink / raw) Cc: guile-user From: Steve Tell <tell@telltronics.org> Date: Fri, 29 Mar 2002 21:26:45 -0500 (EST) So, might it be back for 1.6? I've got some other code that uses optargs and bound. Maybe I'll just leave that on 1.4 and wait and see. OTOH, I'd like to be able to play with goops. if it is to come back it has to be for 1.6 in order to sustain the illusion of not leaving in the first place. the alternative is to justify the API change and then possibly justify its re-addition later, all in addition to retooling client code, which is more messy. currently i'm looking at 1.4.1 issues (getting closer), and i suppose this could fall under the broader question of how/when/why to remove things. somewhat related, my impression is that guile maintainers found a toy (deprecation) and went a little crazy w/ it (because virtualizing interfaces is fun, admittedly). unfortunately, the implication of deprecation is removal at some point, and this requires planning that was not done. dropping `bound?' evokes the same disturbing feeling. so yeah, it's likely i will spot-fix this (maybe this weekend) in the process of getting a handle on 1.4 - 1.6 API changes generally. since this particular fix is small, a patch would be most gratefully received and likely immediately applied (proabably no paperwork required). Curious, what would you do differently if redesigning? well, i would hide SCM_MAGIC_SNARFER and require output file to be specified, omitting guile-snarf writing to stdout in favor of it being able to manage zonking the output file should the cpp fail in some way (model after "gcc -o"). indeed, this is what i did before the work was clobbered by foolish consistency w/ the mal-published past. the macros and what not are fine, IMHO. i'm just grousing because i find it unpleasant to work w/ coding cowboys (yes mvo that's you) who break things gratuitously and leave the pieces for others to clean up, all the while wondering what the big deal is all about. the big deal is all about time and how precious it, wasted by thoughtlessness like this. gak, i'm so worked up right now. Now that its official that every application has to implement its own snarfing system (or go back to manual construction of the init functions), there's plenty of room for experimentation with alternate mechanisms. you mean like comment snarfing (a la doxygen and javadoc)? this is a pretty well trodden path it seems. It actually didn't take very much effort to disentangle my code from its mismash of snarfing macros (a mix of 1.4 and stuff borrowed from the late scwm), so I'm not annoyed. I would like to get back to coding new stuff of my own and off of compatibility-testing though. you and me both! I get the sense that one only gets to break binary compatibility every few years, so there's a strong need to make it count when it does become necessary. Some day soon, one supposes that for example RedHat will decide whether its 1.4[.1] or 1.6 that goes into their 8.x series. Presumably other distributor make the same call on their own schedules. i suppose we should do some research to see what kind of criteria they use to determine upgrade yes/no. in the ideal scenario this wouldn't be far from our own plans. I hope I'm helping make 1.6 more likely to be what gets widespread distribution for two years after that by porting to and testing the 1.5.x ones and asking all these questions. this is very helpful; thanks! (and mvo still has a place in my heart.) brookes' mythical man month points out that coherent vision is necessary for a project's success. for collaborative free software efforts, such a vision must necessarily be shared between both users and programmers, and the only way this happens is w/ incisive questions back and forth. as for longevity of 1.6, i'm still trying to figure that out. if 1.6 is released like 1.4, we can expect more pain. (or maybe someone will fork guile and merge it w/ chicken, any takers? :-) thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-30 4:42 ` Thien-Thi Nguyen @ 2002-03-31 22:06 ` Marius Vollmer 2002-04-01 1:42 ` Thien-Thi Nguyen 0 siblings, 1 reply; 12+ messages in thread From: Marius Vollmer @ 2002-03-31 22:06 UTC (permalink / raw) Cc: tell, guile-user Thien-Thi Nguyen <ttn@giblet.glug.org> writes: > Curious, what would you do differently if redesigning? > > well, i would hide SCM_MAGIC_SNARFER and require output file to be > specified, omitting guile-snarf writing to stdout in favor of it being > able to manage zonking the output file should the cpp fail in some way > (model after "gcc -o"). indeed, this is what i did before the work was > clobbered by foolish consistency w/ the mal-published past. It was not clobbered, please look more closely at what I did. You keep your '-o' option, and the rest of us gets to have command line compatibility with the snarfer from 1.4. This compatibility comes at very little cost, if you want to call it a cost at all: the user is not forced to switched to a better usage of guile-snarf, he is merely allowed to. I also removed the deprecation mechanism in the stable branch because it partly duplicates the mechanism that we have already. > the macros and what not are fine, IMHO. i'm just grousing because i > find it unpleasant to work w/ coding cowboys (yes mvo that's you) > who break things gratuitously and leave the pieces for others to > clean up, all the while wondering what the big deal is all about. Yeah, I was not being very polite by snatching the hacking of guile-snarf away from you. Your first reply did not sound like you wanted to continue, tho. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-31 22:06 ` Marius Vollmer @ 2002-04-01 1:42 ` Thien-Thi Nguyen 0 siblings, 0 replies; 12+ messages in thread From: Thien-Thi Nguyen @ 2002-04-01 1:42 UTC (permalink / raw) Cc: tell, guile-user From: Marius Vollmer <mvo@zagadka.ping.de> Date: 01 Apr 2002 00:06:35 +0200 It was not clobbered, please look more closely at what I did. You keep your '-o' option, and the rest of us gets to have command line compatibility with the snarfer from 1.4. This compatibility comes at very little cost, if you want to call it a cost at all: the user is not forced to switched to a better usage of guile-snarf, he is merely allowed to. what was clobbered was encapsulation of mechanism (internals) which would allow us flexibility in the long run. the general principle i feel appropriate here is that: when starting, start w/ exposing as little as possible; future changes are then relegated to "addition" which is easier to satisfy normal compatibility constraints, than "removal" or "renaming". i felt that this principle was applicable (we are at starting point) because "snarfer from 1.4" was not supported; adding retroactive support is ok if the design was good, but it wasn't, so this was not really justifiable. the cost (aside from listening to me spew on like this) in a decision to expose internals is always latent, which is understandably difficult to perceive. however, i'm sure you know the value of encapsulation because of the `bound?' situation and am very glad to not think about that any more and to watch you DTRT (i do this by watching tasks/TODO -- if you claim some task i won't touch it). Yeah, I was not being very polite by snatching the hacking of guile-snarf away from you. Your first reply did not sound like you wanted to continue, tho. i had invested time to weigh the factors (as i learned them), explain my reasoning, and do the work. why would i want to continue when the job was done? more importantly, on the plate is doc snarfing -- are we going to see the same behavioral patterns repeated? more generally, i'm about to open the doors to give more people write privs -- can you set a good example for these people? thi _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-30 2:26 ` Steve Tell 2002-03-30 4:42 ` Thien-Thi Nguyen @ 2002-03-31 22:46 ` Marius Vollmer 2002-04-24 17:52 ` Marius Vollmer 1 sibling, 1 reply; 12+ messages in thread From: Marius Vollmer @ 2002-03-31 22:46 UTC (permalink / raw) Cc: ttn, guile-user Steve Tell <tell@telltronics.org> writes: > On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote: > > > using some other out-of-band object is possible. (we can bring `bound?' > > back. we just need to finish this iso-API change in the right way, or > > justify in NEWS the new API.) > > So, might it be back for 1.6? Hmm, yes. I removed 'bound?' and related code in 'let-o-k-template' since we can not reveal the SCM_UNDEFINED value to Scheme code. This was a bug and needed to be solved. The 'bound?' functionality itself is not problematic (although not really critical as one can emulate it easily with default-values, as you point out) and we can bring it back. Thien-Thi is right that the removing was done without much planning or work on the real fix, i.e. a 'bound?' that doesn't use the magic SCM_UNDEFINED value. 'bound?' would switch from being a macro to being a function. Would that cause any problems? I have recorded this issue as bug 'optargs-bound-gone'. (Please also see the upcoming announcement of the newish bug data base.) > > wrt other woes, when i took guile-snarf off of noinst_ i did not take > > advantage of the dist-hook to modify already-distributed guile-snarf to > > emit warnings when run, even though i thought about it. my bad. > > I'm glad you didn't - that would be rather antisocial (cf. discussion on > peaceful coexistance of multiple versions) You can't have two versions of Guile on your system _for_compiling_programs_with_ anyway. You can run programs that are linked to different versions of libguile (with the same installation prefix), but you can't install two sets of header files (with the same installation prefix). Leaving a guile-snarf around that does not correspond to the installed header files will only cover up bugs. I think you figured this out yourself, right? > [...] Now that its official that every application has to implement > its own snarfing system guile-snarf will be back for 1.6. > (or go back to manual construction of the init functions), there's > plenty of room for experimentation with alternate mechanisms. This room is still there, unless I'm missing something. You are not forced to use guile-snarf. If you find it inadequate, feel free to experiment with something else. > I get the sense that one only gets to break binary compatibility every few > years, so there's a strong need to make it count when it does become > necessary. In my happy ignorance of real world issues, I don't see why binary compatibility is a big deal. It's an annoying artifact of the usual implementations of the C programming language, but Unix systems seem to deal pretty well with it, anyway, wither by using static linking or versioned shared libraries. It has to catch up a bit when linking dynamically (i.e. via dlopen), but it is manageable. Source compatibility is much more important. Is there more to it? (Likely.) > I hope I'm helping make 1.6 more likely to be what gets widespread > distribution for two years after that by porting to and testing the > 1.5.x ones and asking all these questions. Thanks, that's really appreciated! _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-31 22:46 ` Marius Vollmer @ 2002-04-24 17:52 ` Marius Vollmer 0 siblings, 0 replies; 12+ messages in thread From: Marius Vollmer @ 2002-04-24 17:52 UTC (permalink / raw) Cc: guile-user Marius Vollmer <mvo@zagadka.ping.de> writes: > Steve Tell <tell@telltronics.org> writes: > > > On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote: > > > > > using some other out-of-band object is possible. (we can bring `bound?' > > > back. we just need to finish this iso-API change in the right way, or > > > justify in NEWS the new API.) > > > > So, might it be back for 1.6? > > Hmm, yes. Well, no. :-/ We would be changing the default default value from '#f' to something else. That would be an unacceptable interface change. Since it is easy for the user to provide the functionality on its own, we can just leave it as it is. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: 1.5.6: (bound? ) missing from optargs.scm 2002-03-28 23:32 ` Thien-Thi Nguyen 2002-03-29 6:40 ` Steve Tell @ 2002-03-31 22:59 ` Marius Vollmer 1 sibling, 0 replies; 12+ messages in thread From: Marius Vollmer @ 2002-03-31 22:59 UTC (permalink / raw) Cc: tell, guile-user Thien-Thi Nguyen <ttn@giblet.glug.org> writes: > 2001-05-10 Marius Vollmer <mvo@zagadka.ping.de> > > * optargs.scm (bound?): Removed. We should not play games with > the magical undefined value. > > i don't particularly understand what kinds of games are no longer being > played, nor what is the suggested way to achieve prior functionality. SCM_UNDEFINED is used in C code to flag a variable that exists but has no value associated with it. For example, 'letrec' first creates all new local variables with SCM_UNDEFINED as their value, and any try to read their value will result in an error. It also used as a special not-a-legal-Scheme-value token in C code, for example with scm_list_n. When Scheme code gets access to it, and treats it like any other Scheme value, a lot of assumptions in the C code break down. The old (ice-9 optargs) used this value as the default default value, i.e. the value to use as the default value when no explicit default value was specified. We can use any other unique default default value, for example the result of '(cons* 'unbound)'. It might be tempting to use the un_specified_ value, SCM_UNSPECIFIED, instead of SCM_UNDEFINED, but that wouldn't be really right, either. SCM_UNSPECIFIED is a perfectly usable Scheme value (which SCM_UNDEFINED is not), but it is not really specific to this purpose: you will get it from a lot of functions, and you would then not be able to distinguish whether your keyword has not been specified at the call side, or whether it has been specified but with the unspecified value (which would likely be an error, but you wouldn't notice). _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2002-04-24 17:52 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-03-28 6:30 1.5.6: (bound? ) missing from optargs.scm Steve Tell 2002-03-28 8:52 ` Thien-Thi Nguyen 2002-03-28 23:32 ` Thien-Thi Nguyen 2002-03-29 6:40 ` Steve Tell 2002-03-29 7:44 ` Thien-Thi Nguyen 2002-03-30 2:26 ` Steve Tell 2002-03-30 4:42 ` Thien-Thi Nguyen 2002-03-31 22:06 ` Marius Vollmer 2002-04-01 1:42 ` Thien-Thi Nguyen 2002-03-31 22:46 ` Marius Vollmer 2002-04-24 17:52 ` Marius Vollmer 2002-03-31 22:59 ` Marius Vollmer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).