<Kleptocracy>Is there a way to make guile not complain about the same binding being imported from multiple libraries and just use the latest imported one? <mark_weaver>if a module uses #:replace instead of #:export, then it indicates that it is expected that those bindings will replace previous bindings, and it will not warn. <mark_weaver>on the import side, you can use #:duplicates to tell guile how to handle duplicate imports. <ijp>it can often be cleaner, and more future proof to explicitly import only the subset of bindings you are using, if the subset is small enough <Kleptocracy>Given that I only use string-take from srfi 13 here, that's probably quite elegant <ijp>Kleptocracy: guile includes srfi 13 (and 14) in its base library <ijp>so it shouldn't need imported <ijp>(r6rs libraries excepted) <ijp>only is the way to go <mark_weaver>so use the (import (only (srfi-13) string-take)) syntax <Kleptocracy>Especially when you only use one function yeah I guess <mark_weaver>Kleptocracy: out of curiosity, what duplicate binding was reported? <mark_weaver>If R6RS libraries can't import SRFI-13 without a warning, we should probably fix that. <ijp>mark_weaver: the r6rs string functions may be different because they throw different errors <ijp>I'd need to double check the source <mark_weaver>we really ought to unify this, along the lines of the R6RS exceptions work I recently pushed. <ijp>the only one I see being redefined in (rnrs base) is string-for-each <ijp>it takes different arguments <ijp>it can take multiple strings, srfi 13 string-for-each can take a range <mark_weaver>we should probably change our SRFI-13 module to export 'string-for-each' using #:replace. <dje42>Various Scheme code that I've read use a "make" function to create an object of a certain class. E.g., the GOOPS section of the manual has (define c (make <my-complex>)). <dje42>Is it at least not uncommon for a "make" function to have side effects? <dje42>I'm guessing not, but figured I'd ask. <dje42>I ask because my current version of the gdb/guile port has a function named make-breakpoint that creates a breakpoint object and has the side-effect of installing it in gdb. <dje42>I'm thinking its misnamed, and something like define-breakpoint or create-breakpoint would be better. <mark_weaver>I wouldn't worry about a make procedure having side effects, but personally I don't like any of those names. <mark_weaver>well, I certainly don't like 'define-breakpoint'. create and make are pretty much synonyms, so I don't see either one as better than the other. <mark_weaver>but admittedly, coming up with good names is often hard. <dje42>One thought I had was make-breakpoint (no side effects) + install-breakpoint!. But I can't really think of a need to split up the steps. <mark_weaver>I think the name should indicate not that something is being created or defined, but rather that it's being installed or set or something. <dje42>Not that we aren't into bikeshed territory here :-) but how about create = make + install. That way I can have just create-breakpoint today, leaving make+install for some hypothetical future when the separation is useful. <dje42>[I like create over install ...] <dje42>Naming is hard. But I do like to spend some time on it. <mark_weaver>in my experience, coming up with good names is often the hardest part of any hacking job. <mark_weaver>one question though: you're tying together creation of these objects with installation of breakpoints, but what about removing the breakpoints? <dje42>It's scm_gc_protect_object'd until the breakpoint is deleted from gdb. <mark_weaver>I guess the closest analogue would be ports, which are always opened as part of creation, and it's possible to close them explicitly, but they're also closed automatically if GCed. <mark_weaver>if no references to the breakpoint object remain, is there any way for the breakpoint to be deleted? <dje42>There is the breakpoint-delete! function. It's akin to doing "delete bp#" from the gdb command line. <Kleptocracy>mark_weaver, well, I used srfi-1's make-list and srfi-13's string-take <mark_weaver>I guess I'm not sure why you'd deliberately keep the object alive if there's no way for the program to get at it. <Kleptocracy>And a lot of bindings exported by those libraris were reported as dupes from rnrs (6) <ijp>Kleptocracy: can you paste a list? <mark_weaver>Kleptocracy: thanks for bringing this to my attention. we should change a bunch of those exports to use #:replace instead <ijp>mark_weaver: I'd be a little wary about that in r6rs code <Kleptocracy>Truth be told, I don't really like the srfi naming scheme all that much, I'd rather the string library just exported 'take' instead of string-take, then you could just string:take as a prefix, string:string-take looks a bit silly. <ijp>it wouldn't be portable <ijp>Kleptocracy: they predate a portable module system <dje42>A reference to the breakpoint exists inside gdb. One way to get a reference is with the (breakpoints) function which returns a list of all breakpoints (that are created in gdb). <ijp>that said, I do the same in pfds, and I don't have that excuse <Kleptocracy>I really like how OCaml does this, you just use Float.from_int where Float. is the module namespace <mark_weaver>ijp: I'm not talking about r6rs code though. I'm talking about our srfi-1 and srfi-13 libraries, and perhaps some others. <Kleptocracy>Someone make an SRFI which defines how to rename other SRFI! <Kleptocracy>I'm not sure the problem also exists in normal guile code, I use the r6rs module system <ijp>mark_weaver: for srfi-13, this is not a problem in guile <mark_weaver>my point is that people should be able to import the SRFIs into R6RS libraries without getting a bunch of warnings. <mark_weaver>historically, we've decided whether to use #:export or #:replace depending on whether the export conflicts with something already in (guile). I'm saying that we should use #:replace whenever an export would conflict with either (guile) or (rnrs base). <ijp>I'd like to see the list <ijp>for some, it may be a red herring, and that is a bug <ijp>map is redefined in (rnrs base) <ijp>it was for cycle detection, but we do that in guile now <ijp>but to take the example above, I would *not* like to see string-for-each replace without a warning <ijp>the two have different behaviours, and the user should know about that <mark_weaver>another difference between various 'map' implementations is whether they raise an error when given lists of different lengths. <mark_weaver>I had to implement a bunch of new procedures for R7RS because R7RS stops at the shortest list/vector/string/whatever. <Kleptocracy>WARNING: (guile-user): `map' imported from both (rnrs) and (srfi srfi-1) <ijp>dje42: this seems to be the preferred behaviour in scheme, and haskells zipWithN does the same <ijp>Racket disagrees; I'm on the fence. <dje42>I dunno. I could be misunderstanding, but what if there's a difference in length due to a bug? <dje42>I can see having lazy-map or some such. But plain map should be strict (IMO I think). <mark_weaver>I think that R6RS/R7RS should be able to import a SRFI without getting a bunch of warnings that aren't easy to silence. <Kleptocracy>I think that the srfi's should have a re-export option rather <Kleptocracy>That, or that a user should be able to define an order. <ijp>mark_weaver: 1 and 13 are probably the only real offenders <ijp>Kleptocracy: why 43? <ijp>yes, but the only overlap would be vector-for-each <mark_weaver>Guile doesn't have that one yet, but yeah, that one too. <ijp>which should be the same <ijp>right, but these should all be the *exact* same procedure <ijp>at which point, multiple imports are harmless <mark_weaver>I think it won't complain if the binding is to the same variable. <Kleptocracy>mark_weaver, it shouldn't be hard to steal another implementation right? <ijp>where they *differ* (as with map, and string-for-each above) this should be an error <mark_weaver>Kleptocracy: I'd guess that the reference implementation probably works as-is. <ijp>Kleptocracy: length checking <ijp>(map list (list 1 2 3) (list 4 5 6 7)) <ijp>(@ (rnrs base) map) says error, (@ (srfi :1 lists) map) says ((1 4) (2 5) (3 6)) <ijp>what we could do, is suppress the warnings if the procedures aren't used (which we may do already) <ijp>Kleptocracy: I'd need to double check, but our *implementation* says it errors <ijp>"Implementation responsibilities: The implementation should check that the lists all have the same length. The implementation must check the restrictions on proc to the extent performed by applying it as described. An implementation may check whether proc is an appropriate argument before applying it." <Kleptocracy>"Implementation responsibilities: The implementation should check that the lists all have the same length. " <Kleptocracy>Everywhere I encounter map it has always defaulted to the shorest list for me <Kleptocracy>Doesn't like almopst every scheme implementation just default to the length of the shortest in that case? <ijp>I defer to rfc 6919 on this matter <ijp>Kleptocracy: racket does not <ijp>the r5rs is silent IIRC <ijp>well, it says "they must all be the same length", but everyone does what they like <ijp>the point was: different procedures, different behaviours, silent errors are a no go (IMO) <Kleptocracy>Hmm, racket gives me no error in r5 mode but does in r6. <Kleptocracy>I don't think errors should ever be silent, I just think there should be a flag in the import itself to be able to assign a praecedence to imports <ijp>Kleptocracy: the r5rs says they must all be the same length, but r5rs error behaviour is "do what you like" <mark_weaver>ijp: so then there's no way to import any of the changed bindings from SRFI's into R6RS code without getting warnings that cannot be silenced? <ijp>mark_weaver: they can be silence by not importing those bindings <Kleptocracy>I feel that at the very least different length behaviour should be unspecified in r6 <ijp>mark_weaver: then don't import them from rnrs base <ijp>(import (except (rnrs base) map) (srfi :1)) <ijp>don't error if they aren't used is fine with me <ijp>but if the binding is used, we shouldn't just pick one <ijp>Kleptocracy: why use r6rs modules if you are going to invent nonstandard syntax? <Kleptocracy>Well, I'm saying it should be part of the r6 module system <ijp>if this were any other library than srfis, you would not even be arguing with me <Kleptocracy>At least about the part that there should be a way to resolve conflict ambiguities <ijp>there are four ways to resolve it. only, except, rename, prefix <Kleptocracy>THose do not resolve them, those stop them from happening <mark_weaver>what do other R6RS implementations do when you import SRFI-1 or SRFI-13? <Kleptocracy>Resolving a conflict ambiguity is just defining a system that unambiguously defines which binding should be imported in the event that two bindings with the same name get imported <ijp>the only other one I have installed at the moment is racket, and they do what we do <ijp>but I'd bet good money on the rest doing the same <Kleptocracy>You cannot import srfi1 and rnrs base at the same time without rename or prefix or that stuff. <Kleptocracy>Well, guile gives you a warning but does it anyway, racket just refues to compile <mark_weaver>okay. well, fair enough. if you want to write portable R6RS code, you have to avoid importing the same binding from two libraries, so I guess I'm okay with leaving things as they are. <Kleptocracy>I don't think this is something guile should change but something that should've been in the r6rs module system from the start. <ijp>I know haskell doesn't let you, but won't complain unless you use them <Kleptocracy>Haskell's praefixes are also actual namespaces though <Kleptocracy>As in, in Scheme it is possible to have a library export list:map and still get a conflict even though someone used a praefix. <Kleptocracy>You can't have full library hygiene if you will, it's always possible to break it. <ijp>list:map is an identifier <ijp>right, now I get you <Kleptocracy>You can't just name a function List.map, List. is the namespace, map the name <ijp>well, there are "philosophical" reasons for that <Kleptocracy>The proper way would be (namespace list map) but that would get exceedingly verbose <ijp>which is (apparently) that all identifier unniceness goes in # <Kleptocracy>Well, say #.list.map existed as reader macro for (namespace list map) <mark_weaver>Kleptocracy: Guile has a syntax (@ (srfi srfi-1) map) that does what you want, i guess. <Kleptocracy>Hmm, I guess that's kind of nice, it's not even a reader macro looking at it <Kleptocracy>OCaml, if you just use Foo.bla it actually looks for a file named Foo.ml in the same directory. No need to import it. <mark_weaver>with the guile '@' syntax, you don't have to import either. <ijp>there is also @@, which is @'s naughty cousin <Kleptocracy>I don't really mind that stuff, I think these modules with massive importas at the top often onky importing one binding are overrated <Kleptocracy>If you only use one binding just using something like (@(srfi :13) substring/shared) doesn't hurt <mark_weaver>you can't use the (srfi :13) style with that syntax, nor with most of the guile module import stuff. <mark_weaver>module names like (srfi :13) are only converted to (srfi srfi-13) as part of the R6RS 'import' syntax. <ijp>which is more sensible <Kleptocracy>13 isn't really a number in that sense as much as a name anyway <ijp>Kleptocracy: while they were changing the module system, they figured they'd fix that little detail <ijp>the : was added to the numbers in srfi 97 because module name lists could only contain identifiers (and numbers are not identifiers) <Kleptocracy>Yeah, I know, but I guess the point is that they aren't really numbers in srfi <ijp>the nice thing about srfi 97 was they gave them names as well as numbers <mark_weaver>This conversation involves way too much bikeshedding for my taste. <ijp>Kleptocracy: arguing about irrelevant details, rather than bigpicture stuff <ijp>so say you design a module system, there are many important points to cover: namespacing, module lookup, existence or lack thereof of module functors, etc. etc. <ijp>they will get 10% of the conversation, and 90% will go to the syntax <Kleptocracy>You have to admit that you will never use the srfi identifiers as numbers, you don't add them, compare them, subtract them. <Kleptocracy>THey actually invested time into changing it from srfi :1 to srrfi 1 <Kleptocracy>While the old solution worked fine and is arguably semantically better because they aren't numbers <ijp>they did change more than that <Kleptocracy>Well yes, but they still invested time on changing that part <ijp>as long as you don't propose a unary syntax, I'm happy <ijp>i.e. no (srfi (s (s (s (s (s (s (s (s (s (s (s (s (s z)))))))))))))) <mark_weaver>Why are we wasting time talking about standards that have already been published? Especially given that no one active here on channel had much to do with their creation? <ijp>I just assumed it *was* meant as idle chat <ijp>since it's 3am and I have nothing better to do <Kleptocracy>Either you defend the position that you are numbers, relent that they are not numbers, or I will go crazy, thatis how it works. <mark_weaver>Yes, R7RS allows both identifiers and exact integers in the module name lists. I don't know why they wasted time on that, but frankly I think it's an improvement. <ijp>ditto for #true and #false <ijp>as loath as I am to see more go under # <Kleptocracy>It's an improvement insofar numbers are part of the name. If it makes sense to perform arithmetic on them <mark_weaver>R7RS recognizes #true and #false as alternative syntax for #t and #f. <ijp>I've had bindings for false and true in my utils for a while, but since they don't print that way, it's of limited utility <mark_weaver>btw, I have a fairly complete implementation of R7RS on Guile now. <Kleptocracy>Did they invent that or did implementations actually support that before r7? <ijp>Kleptocracy: with chibi involved, it's hard to say <ijp>alex's shinns scheme implemenation, which aims to be the r7rs reference implementation <mark_weaver>Alex Shinn was the chair of the working group that created R7RS small. <ijp>it's plausible he could add something to chibi, and then propose it, but that's close to conspiracy mongering <ijp>I'm not getting into that discussion <Kleptocracy>Like, the Dutch language academy publishes a new standard every 5 years it seems and a lot of the changes are seemingly just to amke random changes and get paid for it. <mark_weaver>I think R6RS is superior, but some implementors didn't like it, so R7RS was created by the folks that didn't like R6RS, basically. <Kleptocracy>I don't know, it seems like python 3 all over agian. <Kleptocracy>r6 had a major reason to move over from r5, portable modules. <mark_weaver>What really sucks is that R7RS is gratuitously incompatible with R6RS in a number of respects. <Kleptocracy>Would there be if r7 introduced a way to solve the naming conflict? <ijp>the duplicates issue earlier <mark_weaver>oh please, that's totally trivial compared to the substantial differences between R6RS and R7RS. <Kleptocracy>The reason we are talking about nothing at 04:15:26 in the morning <ijp>the promotion of cond expand was weird I though <mark_weaver>it's very silly to declare that you'd switch to R7RS for a single reason, without having any idea what the other differences are. <ijp>Kleptocracy: srfi 1, a way to expand conditionally based on certain aspects of the implemenation <ijp>in guile it mostly gets used for 1/2 differences <ijp>I actually typed in 0 first, and then changed it <mark_weaver>Kleptocracy: I think you'd find that there are far more important reasons to favor R6RS. <ijp>having a standard library that is not completely optional <Kleptocracy>This namespace thing is like non hygienic macros, it's a big deal breaker. <ijp>a portable procedural macro system <ijp><Kleptocracy> standard libraries are bad <ijp>but standards are bad? <Kleptocracy>but a standard should not proscribe which libraries to have <ijp>anyway, this conversation will only rile me up, so I'm off <Kleptocracy>But a standard shouldn't say "You must support this standard!", it should say "If you support it, we'd like to ensure that everyone supports it in the same way." <Kleptocracy>I'm perfectly fine wityh scheme implementations existing that only support integers as long as they advertise it <ijp>just FYI <ijp> leppie: suppose I import two different functions with the same name in iron scheme <ijp> does it error, warn, or pick one? <leppie> in the repl it will bind to whatever was loaded at that point of time, in a program/library it will error as required by the spec <ijp><ijp> leppie: does it error, even in the name isn't used? <leppie> ijp: yes, if it was imported and clashes <ijp><leppie> it also depends where it was imported <leppie> local imports will shadow <mark_weaver>R6RS section 7.1 states "An identifier can be imported with the same local name from two or more libraries or for two levels from the same library only if the binding exported by each library is the same (i.e., the binding is defined in one library, and it arrives through the imports only by exporting and re-exporting). Otherwise, no identifier can be imported multiple times, defined multiple times, or both defined and <mark_weaver>ah, I see that got truncated. It ends with "or both defined and imported." <mark_weaver>so portable code will have to avoid duplicate imports anyway. <mark_weaver>mainly, I just wanted to avoid unavoidable warnings on standards-conforming code. <mark_wea_>Emacs' mode for editing C is extremely inefficient, to the point that it's very painful to use on less powerful hardware. <mark_wea_>I've actually resorted to switching to fundamental mode just to get work done. ***Kleptocracy is now known as Dolfje
<ArneBab__>mark_wea_: regarding multi-language guile: I realized that “keep the language by default” should actually produce the correct results most of the time, because built-in and installed modules should already be precompiled. So it would only become problematic when people mix projects written in different languages and do development in both projects at the same time. <ArneBab__>I had wondered for some time, why I did not experience the problems I expected when I worked with wisp-at-the-REPL. The answer was, that I only used guile-built-in modules and guile-www - both of which where installed via my distro. <ArneBab__>so I think a general automagic solution isn’t necessary. For people who actually need to do cross-language development (like guile-developers who use a different language for testing guile modules), the issue could either be solved with a build-system (dependency on module.go) or some option for use-modules - but most regular users will never need to touch this, even if they use different languages than guile scheme <wackonline>Hi all, I want to ask the define-syntax _ and...Symbols are what mean <wackonline>hi all,i want ask _and... is what mean of define-syntax <waxysubs>The thing is, I'm logged into freenode from my server via waxysubs, and from my laptop via mark_weaver, but mark_weaver can't see that waxysubs is logged in. <waxysubs>must be some netsplit within the freenode network I guess. <waxysubs>also, mark_weaver can't see some of the recent comments on #guix <waxysubs>I logged mark_weaver off and on again, and it still can't see waxysubs, nor any of this conversation, and I can't see the test that mark_weaver just posted. <waxysubs>well, I'm sure they'll sort it out eventually... <mark_weaver>both mark_weaver and waxysubs just saw all the messages they've been missing from each other. <civodul>mark_weaver: there have been series of disconnects; that could be an indication that something is wrong with Freenode ***micro` is now known as Guest3074
<mark_weaver>hmm. does anyone know how to display the contents of a guile hash table from gdb? <mark_weaver>I guess I can come up with something based on the 'pp' macro in gdbinit. <mark_weaver>ah, looks like that macro can be simplified now that we have scm_c_public_ref <civodul>mark_weaver: maybe call scm_c_eval_string("(hash-fold ...)")