<alextee[m]>Is there a convention for differentiating functions imported from each module? <alextee[m]>Like in C you use prefixes and in cpp you use namespaces <spk121>alextee[m]: you can use prefixes using the #:prefix or #:renamer helpers to use-module. I've seen prefixes being used <rlb>alextee[m]: for me it depends on the module's design. If the api names are already somewhat prefixed (or the names are sufficiently distinctive), then I might just #:select the bindings I want, otherwise, I'd likely use a #:prefix. I don't generally pull in all the bindings anymore, fwiw. ***karlosz_ is now known as karlosz
<civodul>it restores previous behavior but does not provide a good long-term solution ***wingo_ is now known as wingo
<civodul>wingo: i haven't checked, on the grounds that it Should Not :-) <civodul>at worse, it's an extra hash table lookup ***karlosz_ is now known as karlosz
<civodul>wingo: my reasoning is that, if you're not using read hash extensions, then all psyntax sees is syntax objects and datums that don't support source properties <wingo>could be! i wasn't sure if psyntax would also have other kinds of datums or not <wingo>but i have paged out the details, as you can see ;-) <sneek>I've been running for one minute and 36 seconds <sneek>This system has been up 1 minute ***rgherdt_ is now known as rgherdt
<ArneBab>If this keeps up the momentum, it might be a launching pad for which it’s extremely important that the decisions taken *now* are the right ones. <ArneBab>^ that’s all I needed to read to know that me participating in that list had a use :-) — I hope I could help by bringing information where it is needed. <drakonis>r7rs-large is taking too long, so this is a positive move <drakonis>i just hope that r7rs-medium is capable of reaching completion before we're all reduced to dust <ArneBab>I see it as a step forward to have a concrete document so R7RS-large can more easily be aggregated and harmonized. <drakonis>i want to see what happens next, but there's really no guarantees on whether the schemes will unify under this particular banner, is there? <ArneBab>I don’t think there is a guarantee, but it looks like there may be a chance to have more easily portable code <drakonis>i'm not sure if the issues with portability are inherent to the community or the language itself <drakonis>the proliferation of implementations with their own specific goals that diverge in ever subtle ways <ArneBab>I think that that’s OK. To get better portability, simply having standard libraries will be a big advantage. <ArneBab>And to make it easy to implement libraries that work on many different systems, the r7rs-medium would provide a viable basis — if implementers actually take it up. <drakonis>would it also make it significantly easier to make libraries that can target multiple implementations? <drakonis>i've noticed that CL has a very strong emphasis on having libraries that work across implementations <drakonis>it would go ways towards dealing with the long standing issue where you have to pick an implementation and the ecosystem of libraries available, rather than the particular niche a implementation targets <ArneBab>yes, it looks like it should become easier to have cross-implementation libraries <ArneBab>though I think it’s already possible nowadays (looking at the benchmarks by ecraven), but we’re lacking the tutorials for that.