<davexunit>would it be wise to write docstrings in texinfo format? <davexunit>or should the docstrings be more human readable? <mark_weaver>I'd recommend writing them in texinfo format. The plan is to render them to plain text, just like we already do with docstrings in SCM_DEFINE forms. <davexunit>mark_weaver: great. I will work on that then. <mark_weaver>davexunit: if you import (texinfo reflection) and then use (help ...) that should show the rendered version. <davexunit>cool. I'm trying to work out a way to autogenerate a good amount of my manual. <davexunit>some things don't have docstrings, like record accessors, but I still want them to show up in the manual. <mark_weaver>we don't have a good way to autogenerate a decent manual from the docstrings. maybe it's a fools errand to even try, dunno. <mark_weaver>for now, it might be better to just extract them somehow, to form the first draft of the manual, and then henceforth maintain them separately. <mark_weaver>maybe someone will come up with a better solution in the future. <davexunit>I think it would be easy enough to iterate through all modules and output docstrings of all exported procedures. <davexunit>and then take your advice and maintain the manual separately from there. <mark_weaver>I could be wrong about all this; it's not my area of expertise :) <davexunit>other languages like python, ruby, java, etc. all have programs the generate docs from comments in the source. <dsmith-work>davexunit: fwiw, the scwm manual is generated from docstrings. It's pretty icky. Nothing near as good as the guile manual. <dsmith-work>davexunit: Also, the intial C macro docstring support in guile was intially from scwm. <davexunit>I guess I just need to bootstrap my manual with a script then. <davexunit>and maintain it in parallel with the source afterwards. <dsmith-work>How many times have you ever followed some documentation link for some project, and it was to doxygen html, and you were impressed with how useful it was? <dsmith-work>It a very attractive idea. I like keeping the docs next to the code and all that. <mark_weaver>from my perspective, part of the problem with generating docs from source is that the ordering of the manual may not match the best order to present in the manual. and what about splitting the docs into sections, chapters, etc? what about other descriptive text that's outside of any particular procedure docstring? <mark_weaver>That said, I can certainly see the benefit of having everything in one place. <dsmith-work>All that ordering and "outside" text is the lot of effort I was talking about. <mark_weaver>I'm sympathetic to the idea of literate programming. It would be interesting to see a literate programming system tailored to Scheme. <jao>they have a very sophisticated thing called scribble that can do it, yes <jao>and apparently many other things <mark_weaver>cool, thanks for the pointer! if it's good, maybe someone could look into porting it. <jao>the do the noweb thing, only better <jao>you can actually embed your own scheme functions <jao>and use them to generate the doc <jao>and they do nice automatic linking to the online manuals and things like that <dsmith-work>Seems to much more useful (Literate Programming) for documenting how something works than a writign a user manual or refernce manual. IMHO anyway. <jao>i tried LP as proposed by Knuth back in the day (with noweb) <jao>and it totally kills the joy of repl-based development <jao>and, personally, i rewrite things too much to be practical <jao>i kind of grow the program, bottom-up, and it mutates and mutates <jao>until i understand the problem <jao>and the solution. and for that, trying to write a lp-like doc is awful <jao>at least in my experience <jao>i could go back when it's done and then write the LP article/book, perhaps <davexunit>makeinfo yells at me when generating a pdf. it complains about not having a top node, but it's not supposed to use a top node... <davexunit>I moved the @menu block elsewhere in the file and it worked <davexunit>I just didn't think that was an issue because emacs autogenerated this file for me. <davexunit>hmm emacs even insists on the menu appearing before the nodes <davexunit>I don't really get why texinfo went from a fast makeinfo in C to a much slower one in Perl. <davexunit>they could make the C makeinfo extensible in guile or something. <dsmith-work>Guile already has some texinfo support. And sxml -> {html,xml} <davexunit>I'm reading the docs on modules, but I haven't been able to figure out how to get all of the exported procedures from a module. <davexunit>there's a resolve-interface procedure, but I can't get it work for me. <davexunit>module-map is always returning an empty list *cky keeps plodding along with the macro conversion project. <mark_weaver>cky: that's great! no need to give it all to us in one big code dump. I'd be glad to accept patches to one macro or module at a time :) <mark_weaver>I'd actually prefer smaller commits to one huge one anyway <mark_weaver>does it make any sense for a texinfo document to lack a top node? admittedly, I don't know much about texinfo, but I assumed a top node was mandatory. *youlysses might try his hand at a DIY Tabletop PC this coming summer -- and thinks it'd be fun to write an interface on-top of Guile-sdl. :^) <mark_weaver>I look at that, and see basically a large tablet computer. the hard part is the software. it would be great to have better multitouch support in a free software stack. <mark_weaver>I get the impression that Xorg and GTK+ have most of the needed stuff at the lower layers, and it's just a matter of having better gesture recognition in the upper layers and the applications. <mark_weaver>I wonder what software they're using in that video, and how much is free software. <youlysses>mark_weaver: To my knowledge wayland will make it easy for clients to handle multi-touch and just generally gestures. Also, it looks more-or-less half is free-software. <dje42>Suppose I have a smob that I can do eq,ne,lt,le,gt,ge comparisons on. What do I name the functions? I'm not happy with anything but what about foo-eq? [yeah, maybe not ideal] foo-ne? foo-lt? and so on. <dje42>I realize Guile doesn't have (!= a b) so one can argue to not have foo-ne? <mark_weaver>well, look at strings for example. there's string<?, string<=?, string=?, etc. <mark_weaver>and indeed, for !=, the convention is to just say (not (string=? x y)) <dje42>I'm all for "Consistency Is Good." <jmd>I thought I could ignore an ERROR like this: (catch #t <jmd> (set! al (read-dot-tools-file ".tools" al)) <jmd> (lambda (k . a) #t) <jmd>But that doesn't seem to be the case. <wingo>you need to wrap the catch body in a lambda <wingo>said another way: catch is a function that takes a key and two procedures, the body and the handler <ArneBab_>wingo: I also stumbled over that. Can you explain why the catch body needs to be wrapped in a lambda? <civodul>ArneBab_: i think the answer is "that's the way it is" :-) <civodul>and, as usual, you can always define a macro that makes it look the way you prefer <ArneBab_>civodul: I just don’t understand the reason for that. Is it because (set! …) does not return a function but the result of the function call? <civodul>the return value of set! is unspecified <civodul>but what does it have to do with 'catch'? <ArneBab_>I try to understand why catch needs lambda… <ft>You can hand it a function name, or an anonymous function. Makes sense if you're in a situation where catch bodies look very similar. ***aidalgol` is now known as aidalgol
***ijp` is now known as ijp
<ijp>ArneBab_: catch needs lambda because catch is a function <ijp>functions totally evaluate their arguments, do there is no way for it to perform the setup needed for 'catching' anything until after the error is thrown <ArneBab_>ijp: ah, ok. Thanks for your explanation! <ijp>(list (launch-the-missiles)) -- list doesn't know anything about no missiles just being lauched, it just gets a value :) <ijp>it's funny how launching missiles became the standard example for side effects <ArneBab_>I guess, that’s why you want to know macros when handling missiles ;) <jmd>How do I discover what the second arg to catch should be? <ijp>well, really it depends on the tag <jmd>In other words, when the documentation says (for example) " If a file cannot be opened with the access requested, `open-file' <jmd> throws an exception." How do I find out WHICH exception it throws? <ijp>for the ones thrwton misc-error, there is a set format <ijp>s/misc-error/scm-error <ijp>jmd: if you look up the docs for scm-error, you see that there are five arguments key, subr, message, args, data <jmd>But that doesn't help me much. I need to know what KEY it was called with. <ijp>yes, it's rather a pian in the ass <ijp>errors are a part of the API and are really supposed to be documented <jmd>Is there a laxative for this particular pain in the ass? <ijp>so what you should probably do is, use #t for the tag to catch them all <ijp>and use a generic handler that prints out all the arguments <ijp>...and then go back and fix it <ijp>(catch #t (lambda () (open-file "/tmp/fooo" "r")) list) <ijp>(system-error "open-file" "~A: ~S" ("そのようなファイルやディレクトリはありません" "/tmp/fooo") (2)) <ijp>so in that case, the tag was system-error, which has it's own annoyances <ijp>jmd: please do moan about this situation on the mailing list <ijp>but going through and fixing all the docs to refer to errors is a slog <ijp>which reminds me, I never submitted that patch to make all the examples include their imports <civodul>there's system-error-errno to extract the errno from a 'system-error' arg list <ijp>in order to use it, you are supposed to have (lambda (tag . args) ...) which is crazy <ijp>er, not even that, (lambda args ...) <mark_weaver>Exception reporting is a mess in Guile. Supporting something like R6RS conditions by default would be a huge improvement, IMO. <mark_weaver>my preference would be to change the core code to generate R6RS conditions, including a &guile condition object that contains the legacy argument list for backward compatibility, such that legacy 'catch' forms would extract the arg list from the &guile condition object. <wingo>it could go the other way around, dunno -- that's not a very user-visible change afaik <wingo>the one problem i have with r6rs exceptions is "guard" <wingo>which requires rewindable continuations <wingo>but you can do something useful without guard <mark_weaver>we could have a lower-level primitive that does something more sane. <mark_weaver>I confess I don't entirely understand the issue. Is the problem that the condition-like tests in a 'guard' have to be evaluated in the dynamic context of the guard form (as opposed to the context where the error occurs) ? <wingo>mark_weaver: yes -- and that if they fail to match, the dispatch returns to the point of the throw to continue walking the handlers <mark_weaver>I see. does R7RS have the same problem? I remember you complaining about that on the R7RS list, but I don't remember how it was resolved. <wingo>which always sounded incredibly bogus to me that you would want to do that while handling errors <wingo>yes it is exactly the same issue in r7rs <mark_weaver>would this issue not exist if not for the pre-unwind handlers? <wingo>but there is a with-throw-handler primitive in r6rs and i think r7rs that avoids this, afaik <mark_weaver>if there were no pre-unwind handlers, then it seems to me that a unmatched guard wouldn't have to rewind, but rather just continue unwinding, no? <wingo>guile has pre-unwind handlers though, of course, and with good reason <wingo>guile steps around this issue by selecting the catch handler before unwinding, using that hacky tag matching thing <mark_weaver>so I guess our current R6RS 'guard' implementation is not quite right. <wingo>i thought it used call/cc, and if so it's fine; otherwise it isn't right <mark_weaver>I'm not sure either. I looked at it a while back, but my memory is fuzzy. <mark_weaver>wingo: it looks to me like the Guile's R6RS 'guard' evaluates the tests in the dynamic context of the throw/raise. <wingo>humm, i wonder if i had something to do with that code ;) <wingo>that was my proposal to the r6rs / r7rs folks <mark_weaver>doing it the right way, with call/cc, sounds much less efficient. <mark_weaver>but here I think it's worth the efficiency hit to be correct. <mark_weaver>I guess the inefficiency would only occur when an exception is thrown. <mark_weaver>I have a pending patch to improve the R6RS exception handling, so I'll integrate these improvements into that work. <ijp>why is there a separate goops info file? <ijp>and assuming it isn't bitrotten, why is the tutorial in a separate info file? <ijp>ah, that must be because I still have 1.8 around <mark_weaver>goops-tutorial.texi has only texinfo comments in it, and should probably be removed. <ijp>did we stop installing those? <mark_weaver>I've noticed there's quite a bit of cruft in the doc directory <mark_weaver>I don't know, you can find out as easily as I can :) <ijp>well, I don't see the tutorial in the repo, so I suppose that's a yes <ijp>which is one less doc thing to worry about <ijp>did we come to a decision about manual reorganisation? <dsmith-work>ijp: You know at one time, goops was a completely separate project... <ijp>this is just a case of two installs confusing me <ijp>sections 2,3, and 4 are a little haphazard <shanecelis>I'll get over it, but doesn't let have too many parens? I mean, it made more sense when you didn't have to bind the variables to any value (let (a b c) #t), or there was an implicit begin block (let ((a #f #t)) a), but let has a very rigid form. <ijp>the former makes a little sense, but the latter one makes no sense <ijp>it might make some sense in a let*, but not in let or letrec <ijp>(begin (do-something) (let ((a (do-another-thing))) a)) <wingo>dunno, i can't say it ever bothers me <shanecelis>(let ((a (begin (do-something) (do-another-thing)))) a) *wingo almost never uses begin, except when writing macros <ijp>I have been writing scheme since 2008, and I have never once had a begin on the right side of a let <shanecelis>wingo: what do you use for multiple form consequents in an if? cond? <ijp>the default of #f (or #<unspecified>) makes a little sense for imperative code, but I'd say it's probably as bad as undeclared variables in C <wingo>shanecelis: match, let, and lambda, basically <wingo>shanecelis: also when and unless <ijp>r6rs allows (define foo), but I'm in two minds about it <ijp>I mean, it's not technically any worse than a placeholder like #f <ijp>but except for writing `define-values' I'm at a loss to when I'd use it <ijp>are any of you still using quack in emacs? <dsmith-work>shanecelis: The very first time I looked at let, it *did* seem to have to many parens. But then I "got" it, and it makes perfect sense. <ijp>I've been without it for a short while, and the only thing I've noticed, is that I get slightly less syntax highlighting <shanecelis>ijp: couldn't a (let (a b c) ...) have a, b, and c as unbound? <ijp>unbinding a variable makes no sense <ijp>(ignoring the top level) <shanecelis>ijp: Yeah, if you try to access them before they're defined/set, you get a variable unbound error. <ijp>we could, have that bind it to some placeholder that may be unspecified <shanecelis>It's silly and not worth it, I know, but I want those parens to do some work! <wingo>shanecelis: so it's really only the left one that has to work, with paredit :) <ijp>I know what you are after, and letrec does it, but I don't think "unbound" is the correct way of thinking about it <ijp>but I'm splitting hairs *ijp unsubscribes from more bacn <ijp>on a tangentially related matter, what languages require you to explicitly declare variables that may be mutated by different threads? <ijp>well, except for haskell-type mvars <ijp>wingo: synchronised is on variables and not just methods? <wingo>ijp: "volatile" is what i am thinking about <ijp>dsmith-work: I thought volatile was just an optimistaion in C? <dsmith-work>But if you are working with HW or threads, you *better* declare that thing volatile... <ijp>anyway, I figured it had to have been done before <ijp><ijp> ,ijps-third-law <fsbot> ijps-third-law is, like, There is no idea so stupid someone hasn't came up with it before you <ijp>smart ideas are exempt from the law, naturally ***ijp` is now known as ijp
<stis>Hmm If I get it my way we can soon link in iso-prolog programs and then use the predacates in kanren. <ijp>stis: you wrote a (language prolog) ? <ijp>me and mark_weaver were going over ways to have non-scheme modules the other day *ijp looks through the logs <stis>I had a try of that before, working on a cleaner version right now, <stis>I'm tryying to be more close to the iso-prolog standard <stis>The old code is horruble <ijp>basically, the file extension route might be our best bet, the problem is making it extensible <stis>I'm trying hard to design an extensible syntax this time. <stis>The problem wiht prolog is that the standard is not that well followed <stis>Also we would allow people to design goals that make use of kanrends condi etc. <stis>and be able to use them inside pprolog as well <stis>Anyhow I will , for the first version add an include macro, so that e.g. you will need a wrapper module <stis>hence the file extension mechanism is not there in the first version <stis>else you will just import theprolog predicates for your kanren work aat your will <stis>anyhow need to zzzz, cheers! <ijp>nah, I have one already <ijp>I'm a just leave this here (define (flatten ls) (define (fl l) (cond ((null? l) (make-dlist)) ((pair? l) (dlist-append (fl (car l)) (fl (cdr l)))) (else (make-dlist l)))) (dlist->list l)) <ijp>hard to do that when I typed it right into my irc buffer <taylanub>I see what you're doing though .. I suppose a dlist is something you can append to efficiently. <ijp>that's basically all it can do though <ijp>it's mostly a reminder that you don't have to give up beautiful code if you change the representation <ijp>"<mark_weaver> to reduce the number of stat calls, I think we should actually read the directory listing ourselves and look for filenames of the form FOO.EXT." <mark_weaver>civodul: for background: the reason we want to support more extensions is to provide a way to determine the language of a module. <mark_weaver>I've been watching occasionally, but am busy with something so can't talk much. <ijp>the big reason is that it is onerous to make people have to modify a module in a guile supported language, in order to run it or include it <ijp>either by changing the extension, or by including some sort of language identifier in the source <mark_weaver>civodul: (also, I'm not thrilled with the idea of forcing people to use .scm for code written in another language, e.g. elisp, ecmascript, lua, etc) <mark_weaver>the problem with the identifier-in-the-source approach is that it puts constraints on the syntax of the languages supported for modules. <ijp>and it doesn't help with discovery either <mark_weaver>how can you parse the file before you know what language it's written in? <ijp>wrapper modules sorta work, like we have for C extensions <taylanub>A solution similar to file-local variables of Emacs could be used, where the first/last n characters are scanned for a certain sequence, such that it could appear in the comment of any language. <ijp>we do that scanning for encoding already <ijp>but now to load (foo bar) you need to check every file beginning with "bar" in the foo directory <ijp>which is even more expensive than what we do now <taylanub>I think we should be fine if we start with .scm. :P <dsmith-work>May or may not be an issue, but different platforms do reading dirs differently. Or might return them in different orders. It might be a "now you have two problems" thing. <ijp>yes, that is a concern <ijp>we could explicitly disallow/unspecify the conflicting suffix case <taylanub>Don't we just have to search for extensions we support so far ? Why do we need to list directories at all ? (Sorry if I got the whole problem wrong.) <ijp>taylanub: the problem is that for N suffixes, we may have to do N stats <ijp>if you read the directory, you can check all the suffixes at once with no extra penalty <dsmith-work>And reading the dir and groveling though it by hand might be cheaper.. <dsmith-work>What if there are more than one file with a matching extension? foo.scm and foo.sls <ijp>I think ours are implicitly ordered by the %load-extensions list <ijp>which is (".scm" "") by default <ijp>well, one thing to do would be to read all of the directory in (is a max size on linux for them?), and check for them in %load-extensions order <ijp>but I think then we may be lose the advantage <ijp>strictly, we don't say that %load-extensions searches in order <ijp>hmm, and the manual says the default has "" first, my bad <civodul>could %load-extensions be extended only when the current language demands it? <ijp>civodul: well, the problem is if scheme code then wanted to use a non-scheme module <ijp>since scheme is the current language, you wouldn't extend it, and then you'd miss the file altogether <ijp>the problem is the mixed case, not the single language case <ijp>one language is easy <mark_weaver>civodul: btw, in 2.0.9, it appears that if you pass the --language switch, or set (current-language), and then load a module that is not yet compiled, it will try to read it using the wrong language (not scheme). <mark_weaver>the reason this came up is because we realized that Arne's creation of his WISP language, and the idea of emacsy using a noweb language instead of reader extensions, won't work properly in 2.0.9. things will start to break if there are uncompiled modules. <mark_weaver>hence the need to improve the logic that decides what language a module is written in. <alexei_>did you consider (use-<language>-module ...) <ijp>well, I suggested a language keyword <mark_weaver>alexei_: the user of a module should not have to know what language a module is written in. <ijp>but then a module is no longer an abstraction, _and_ it means we need to extend the module system of any other supported language <mark_weaver>alexei_: what if the author of that module changes the language it's written in? <ijp>civodul: though, I do think that changing the ordering based on the current language might be a good optimisation <bipt>there is, also, the option of placing module definitions in separate files, as in scheme48 and sml, and specifying the language in the module definition rather than having a global extensions list <ijp>I covered that situation already, when I suggested a wrapper module <alexei_>Btw, how do you (search-path %path directory) ? <ijp>it works, but it's not optimal, and it requires a new scheme file for every library in $language you want to use <ijp>I am very interested in having other languages work AS IS <ijp>and if you have a module definition, you could just specify the files directly <alexei_>one can also put a directory "manifest". Like __init__.py or similar <ijp>though __init__.py does pose an interesting problem for the suffix case <mark_weaver>alexei_: I'm not sure what you're asking, regarding (search-path %path directory). Can you rephrase? <alexei_>search-path does not find directories, only files. Why is the limitation? Is there a workaround? <ijp>search-path can find directories, if you use a "" suffix <bipt>i'm mostly interested in languages where there's not a "natural" mapping from individual files to guile-style modules, so integrating their libraries will require additional configuration one way or another <ijp>which is in the default %load-extensions <alexei_>ah, right. I forget about extensions. <ijp>bipt: I know, it's going to be a headache <ijp>it's fortunate guile-python never went anywhere, they'd have hated this one <mark_weaver>well, we could generalize the module-finding machinery. <mark_weaver>it could first use the current strategy, and if that fails, it could continue to try using some other strategies that could be dynamically registered. <mark_weaver>what kind of strategies would be needed for python and for the languages bipt is interested in? <bipt>so for CL, for example, i wouldn't find it too inconvenient to require a modules.scm packages or similar, vs. having a module definition written in portable CL. i also think ML-style module features are more natural with separate configuration, at least based on my limited experience with scheme48 <ijp>you need to pass them explicitly into search-path <ijp>and search-path is (search-path path filename . rest) <ijp>it says rest is a list of extensions trings, but it's not clear to me whether that is an actual list you pass in, or you pass them in individually <mark_weaver>you pass in an actual list as the optional third argument. the optional fourth argument is the 'require-exts?' flag. <ijp>(search-path %load-path "quickcheck" ".fizzle" ".fozzle" ".sls") $13 = "/home/ian/lib/quickcheck.sls" <mark_weaver>ah, there's a hack for 1.8 compatibility that accepts a different convention. <ijp>(search-path %load-path "quickcheck" (list ".fizzle" ".fozzle" ".sls")) $14 = "/home/ian/lib/quickcheck.sls" <mark_weaver>see scm_search_path in load.c, specifically line 688. <ijp>if require-exts? is new, then the docstring doesn't mention it <mark_weaver>it's in the manual. the docstring should be updated. <mark_weaver>though the manual is unclear. I don't understand what the flag does, to be honest. <ijp>so you've either found a bug or this behaviour was changed between our versions? <mark_weaver>ijp: you were mistaken. search_path in load.c specifically checks to exclude directories. <ijp>mark_weaver: ah directories <ijp>yeah, I got my wires crossed <mark_weaver>alexei_: I think the problem with allowing 'search_path' to find directories is that it could find false positives, given that modules are allowed to have no extension at all. <ijp>it also breaks in a very common case <mark_weaver>anyway, it's not hard to write something that iterates over %path and does stat calls. <ijp>when you have a (foo bar) and a (foo bar baz) <ijp>so it would probably break every module I've ever written <ijp>(to abuse the term module for a moment)