<xuser>or are .go files meant to be linked with .c files only? <mark_weaver>.go files are treated more like a cache. you don't generally ask to load or run a .go file directly. instead, you ask to either use a module, or load a .scm file, and if an associated .go file is present then it will be used. <mark_weaver>and how you load or run it depends on the nature of the associated .scm file. some .scm files are modules, some are scripts. <mark_weaver>what is the nature of the .scm file that was compiled into that .go file? <mark_weaver>does the script start with "#!"? if so, you just make the original script executable and run it directly. <mark_weaver>if the .go file is present in the cache (and is fresh), it will be used. otherwise, the file will be compiled into a .go file first. <mark_weaver>if the script simply contains a set of expressions to be evaluated, then you can just say "guile <script-name>" <xuser>mark_weaver: yeah, just trying to get familiar with the guile enviroment for learning scheme <xuser>mark_weaver: why is -s recommended for hashbangs? <xuser>mark_weaver: or what is the difference from running -s in the command line and in a shebang? <xuser>I meant shebang no hashbang ;) <xuser>nevermind, is the same :), I mean what does -s actually do? <mark_weaver>well, if you put a shebang at the top, then the script itself can be executable as if it were any other program. <mark_weaver>as for why bother with -s, I guess maybe it's so that it will work with any filename, even filenames that start with a dash. <xuser>mark_weaver: is that the only reason for -s? <mark_weaver>but to be honest, I'm not sure. these decisions were made over 15 years ago, long before I got involved. <mark_weaver>as far as I can tell, there's no reason to use -s except to be robust in the case of weird filenames. <mark_weaver>xuser: if you use emacs, then I also recommend checking out "geiser", which is a great package for interacting with Guile. <xuser>mark_weaver: I use vim actually :), but tempted to just go with emacs for paredit and geiser <xuser>mark_weaver: do you use it with paraedit? <mark_weaver>yes, I use paredit. highly recommended, but there's a bit of a learning curve. <xuser>mark_weaver: I'll start with geiser only then, to start <mark_weaver>fwiw, I have extensive experience with both emacs and vim -- I used vim for many years as my primary editor, and still use it occasionally (especially when root) -- but for Scheme (or any Lisp really), Emacs is much better suited. <xuser>emacs keybindings interfere with the world :) <xuser>yes, that is what hear, nothing beats emacs for a lisp. <mark_weaver>yeah, you'll probably find paredit a bit hard to handle at first. but at some point, when you have some time to spare to learn it properly, it will be well worth the time. <mark_weaver>as for emacs keybindings interfering with the world: yeah, it's true that the default configuration of modern desktop environments often steal some very important emacs keys (such as control-space), so you'll probably need to tweak your desktop config to cope with that. <xuser>mark_weaver: true, I'm going through the emacs built-in tutorial and had already issues with keybindings <xuser>mark_weaver: I'm on windows :), using putty for sshing to a debian box <mark_weaver>okay, I've never really used windows myself, so I can't help with the specifics, but presumably there's some way to configure things so that windows doesn't steal the important keys, at least within putty. <xuser>already hit two problems but nothing big, ctrl+b interfers with tmux and the right alt key is broken in putty for emacs :(, but it can be fixed <mark_weaver>funny thing is, I don't think I ever use my right alt key. <xuser>mark_weaver: how do you alt+v? ! <mark_weaver>I use GNU screen when I need a terminal multiplexer, and for what it's worth I use Ctrl-\\ as my escape key. I found it doesn't conflict with anything else I need, and I can type it easily. <mark_weaver>I alt-v with my left thumb on the left alt key, and my index finger on the v. <xuser>yeah, I'm remapping ctrl+b in tmux to ctrl+z, is there a ctrl+z in emacs? :) <mark_weaver>in emacs, ctrl-z suspends the frame, which I've never found a need for. <xuser>mark_weaver: geiser shouldn't have any problems running in emacs console right? <xuser>mark_weaver: what DE you use? <mark_weaver>by console, you mean emacs in text-only instead of graphics mode? <mark_weaver>just about everything in emacs works fine in text-only mode. <xuser>mark_weaver: nice, debian wheeze/stable is solid, its great if you don't care about bleeding-edge <mark_weaver>RMS uses Emacs in a text console, so that ensures it's well supported :) <xuser>you must admint pkgs are a bit outdated ;) <mark_weaver>that's certainly true. I used to care more about living on the bleeding edge, but nowadays I mostly just want a desktop that works without bugs. <mark_weaver>for the programs I care about being fresher, I just compile them from source, and I use GNU Guix to help with that. <xuser>yeah, I'm going that route to, for some packages you can just use backports or compile to your home dir, that's what I did with guile <xuser>hmm, I should check out Guix <mark_weaver>yeah, the only thing that's not really feasible to compile from source (without losing the stability that I care about) is the desktop environment itself. <xuser>yes, that would be a pain :) <xuser>mark_weaver: have you tried Racket? <mark_weaver>I've played with Racket some. very nice system, for sure. <xuser>with DrRacket is how I came to know the power of the REPL is lisps <mark_weaver>However, Racket is more of a static system, where I prefer a more dynamic one. What I mean is that Racket's modules are immutable. You cannot freely redefine procedures in a Racket system, and have the entire system start using the new versions. <xuser>mark_weaver: you mean like redefine procedures live? in a running program? <mark_weaver>also, when I need object-oriented programming (which I use sparingly), I must prefer a multiple-dispatch system like GOOPS (which is based on CLOS) to the more traditional single-dispatch OO system that Racket is based on. <xuser>Racket has great docs but I haven't go to much through the Guile ref <mark_weaver>for example, in Guile, you can actually add your own numeric types and add methods to basic operators like '+' to operate on those new types. then all the existing code in the system that uses + will work on your new type. <xuser>mark_weaver: oh that's nice, and very common in Ruby also <mark_weaver>Whereas the Racket community seems to consider that undesirable, on the basis of robustness. <xuser>yeah, in ruby they call monkey pacthing :), which some don't like <mark_weaver>on the other hand, I must admit that Racket is on the whole a much more polished system than Guile is at present, and indeed Racket's documentation is a lot better. <mark_weaver>in guile, it's not quite monkey patching in the usual sense. the primitive '+' operator first handles all the built-in numeric types, and then if it finds that it cannot handle the arguments, it dispatches into GOOPS. <mark_weaver>so there's no performance penalty whatsoever for adding new methods to + (or any of the other numeric ops) <xuser>Racket people semms to make more noise and gets more attention, it also has well Professors behind it <mark_weaver>Racket is a top-notch system, there's no question about it. <xuser>I think I'm going to go with evil emacs mode for know :) <mark_weaver>Guile is more based on the philosophy of Emacs. A living system that can be freely modified while it's running, so it almost never needs to be restarted. <mark_weaver>Whereas Racket is a better choice if you want to build on top of modules that are guaranteed to not change underneath you without restarting. <xuser>mark_weaver: how about concurrency in Guile? is there Guile way to go about it? <mark_weaver>Guile has support for POSIX threads, and there have been various high-level concurrency systems built on top, but no coherent story as of yet. <mark_weaver>it wouldn't be hard to build some nice modern concurrency primitives in Guile, but at present I'm afraid it's a weak area for us. <mark_weaver>I actually have some items on my Guile TODO list relating to this. I'd like to support a few different concurrency models. <mark_weaver>At a low-level, I'd like to add support for the same kind of memory barriers that C11 and C++11 include. <xuser>mark_weaver: you are Guile core dev? <mark_weaver>At the higher-level, I'd like to add support for a few different systems. I'd like to support software transactional memory, for those who still prefer to see an illusion of a shared memory with sane semantics. but we should also have message-passing approaches. <mark_weaver>out of curiosity, do you have a favorite concurrency model that you'd like to see supported? <xuser>mark_weaver: message-passing <mark_weaver>yeah, that's certainly the best way to go in the long term. <xuser>I think Haskell implements all concurrency models :) <xuser>I haven't played much with many concurrency models but have read about them <mark_weaver>I think something like that would be good to support in Guile. <mark_weaver>someone just recently started working on that for Guile, but at this point it's very preliminary. <xuser>mark_weaver: that's great :), kudos for getting it into the project <xuser>you are a top contributor ;) nice <mark_weaver>I can't take any credit for the early termite work, but I do agree it would be a good thing to have, and I intend to make sure it gets done, and done well, at some point. *xuser hasn't read about memory barriers in C11 <mark_weaver>the memory barriers don't have so much to do with C11 or C++11 as much as with the underlying hardware approaches to shared memory in multiprocessor systems. the C11 memory barriers are just an attempt to find common ground among the different approaches, for the sake of portability. <xuser>mark_weaver: great attitude! After looking at several scheme implementations, Guile is great <mark_weaver>but I guess that's obvious, since I spend so much time on it :) <mark_weaver>it definitely has its rough spots, but we're very busy polishing :) <xuser>getting late here, nice talking to you and thanks for sharing! <youlysses>Is guile-emacs at-all usable now? Also, is there any general information out-there to track the progress of such? All I can find is the initial GSOC posting. <mark_weaver>youlysses: bipt is the one to ask, but he's not very communicative. maybe looking at that git repo is the best way to see what's happening. <mark_weaver>youlysses: I vaguely remember hearing that guile-emacs is already quite usable, but doesn't yet use the Guile implementation of elisp by default. *wingo going to mail cps patches to the list this morning <youlysses>mark_weaver: Oh, cool! Well that makes me at least relatively hopeful. :^) <bipt>youlysses, yes, the wip-guile branch should behave identically to emacs from bzr *youlysses wishes he was currently had the technical skill to be of some-help -- he's really excited by the possibilities it'll give the environment. <bipt>and tracking git+emacswiki is the best way to monitor minor changes (major updates are sent to guile-user and emacs-devel) <bipt>youlysses, testing is helpful (-: <youlysses>bipt: Over the weekend, I'll be sure to attempt a build and hopefully I'll have the time to play-around a bit. :^) <civodul>bipt: i got positive feedback from jave about Guile-Emacs <youlysses>Ok, Bed-time for now -- a bunch of Homework due later today. o/ <bipt>this works now, btw: (eval-scheme "(compile '(let ((x emacs-version)) (eval 'x)) #:from 'elisp #:to 'value)") => "24.3.50" <bipt>that's guile-elisp binding a variable, calling the normal emacs `eval' subr to get its value, and getting the correct result <bipt>which is quite simple, but hopefully i can replace the emacs evaluator this weekend <civodul>funny, because emacs-version shows up as a Lisp function <taylanub>bipt: Wow, I hear so little from you I was worrying about the progress, is Guile's Elisp implementation fully complete now ? I wonder how you solved the nil/t being symbols issue ? <mark_weaver>taylanub: I meant to chime into that email discussion. <mark_weaver>taylanub: one thing to keep in mind is that there's no perfect solution to integrating #nil into a Scheme environment that treats () and #f as distinct objects. So forget about perfection. <mark_weaver>for example, consider this thorny problem: it is not uncommon for elisp code to receive a result that is conceptually an empty list () from one function, and return it in a context where it really means boolean false. <mark_weaver>now, if the function that it called to get the list is actually implemented in Scheme, the value in question might be '() instead of #nil. <mark_weaver>but now scheme code will interpret that as a true value. <mark_weaver>so unfortunately, the best we can do is to find heuristics that get it right most of the time. <mark_weaver>that said, I wonder how much elisp code actually needs to view #f, #t, and #nil as a symbol. <mark_weaver>for most purposes, elisp should see (), #f and #nil as all being the same value. <mark_weaver>and then there's the more common issue that Scheme code should treat () as true and #f as false, but those two values are mashed up in the elisp world. <mark_weaver>so what we've done essentially for Guile is to arrange for #nil to be treated as both a false value and the empty list, but that's not quite right either. <bipt>taylanub, i used your patch for t/nil; additionally, elisp symbols are now scheme symbols, and their values in various namespaces are stored in guile modules *wingo very pleased at getting cps foo wrapped up <mark_weaver>bipt: is taylanub's t/nil patch in the public git repo at hcoop.net? can you point to the relevant commit(s)? <mark_weaver>part of the reason I ask is that if it's similar to the patch taylanub posted to guile-devel, I know of some ways to make some of the tests significantly faster. <mark_weaver>hahaha. well, the lisp booleans fit in a cube. you need only think in 4 dimensions if you include the other IFLAGS :) <wingo>civodul: you should steal some work time to look at that cps code :) <wingo>it's also in wip-cps-for-merge <civodul>i read the CWCC paper during the holidays, BTW <civodul>nice read, very instructive, only some parts were harder to read <wingo>yes, i have re-read it many times and i still get details when i re-read it <mark_weaver>wingo: fwiw, I have doubts that having a special $ktrunc continuation type is a good idea. <wingo>mark_weaver: you might well be right :) <wingo>there is not a continuation type that binds rest arguments tho <wingo>so we would need to replace it with something <mark_weaver>the main thing is, I think that truncation should not be part of the core semantics, but rather a consequence of treating single-value continuations as (lambda (x . _) ...) <wingo>from my POV we could just rename ktrunc to something, and always throw in a rest argument -- it would be basically what you are saying <wingo>except we should not do that for call-with-values <mark_weaver>of course this would make continuations with rest arguments the (overwhelmingly) common case. <wingo>for primcalls and other things obviously they go away <wingo>we would have to be sure to optimize it appropriately, which seems possible <wingo>ktrunc is not very nice and it would be good to get rid of it <wingo>at the same time we could introduce other forms of allocations, whereby a rest list could be allocated to every slot from register N to the SP <wingo>for that we would probably need to compute a linear continuation order before going in to slot allocation, so we can easily look forward/back and see if that allocation is even possible <wingo>perhaps you have good ideas for allocation :) <wingo>what's there is pretty basic as you have seen -- it appears to work but something more global would be nice <mark_weaver>ijp asked how well we handle (lambda args *foo* (apply values args)) the other day, and I discovered that we handle it rather badly right now. <mark_weaver>is that a case that could be handled by simply leaving the values on the stack without moving them? or would they have to be moved up or down by one slot? <mark_weaver>(I'm not sure it's a common enough case to worry about though) <wingo>in that case i would be tempted to evaluate *foo* in a separate frame if it doesn't reference args <mark_weaver>well, we can worry about these fringe optimizations later. my main concern is to clean up our truncation semantics. <wingo>by cps representation, do you mean the unparse-cps representation? <wingo>or do you mean the language itself? <mark_weaver>I spent some time thinking about unparse-cps, btw, and there's a thorny issue that I can't quite figure out. <mark_weaver>I can't simply mimick the 'build-cps' syntax, because that often involves creating gensyms for continuations behind the scenes.. <mark_weaver>continuations that are not provided in the build-cps syntax. <mark_weaver>on the one hand, I'm tempted to elide some of those continuations that we don't need to see. <mark_weaver>but on the other hand, when debugging, we often need to see all of the continuations. <wingo>perhaps a parameter would be appropriate <mark_weaver>so what I'm left with is that maybe 'unparse-cps' should take some keyword arguments to allow some of the details to be left out. <wingo>defaulting to elide "trivial" continuations <mark_weaver>for example, the CPS to reference a top-level variable is rather large. <mark_weaver>it would be nice to collapse common things like that to something simpler, for most (but not all) purposes. <wingo>another option would be to print in SSA style, with basic blocks <wingo>it's not always what you want, but sometimes it can be useful <wingo>and can remove the pain of nesting <mark_weaver>one other (unrelated) question, before I forget: in the kennedy paper, contification involves checking that not only the normal continuations are the same for all calls to a function, but also the exception continuation. <mark_weaver>but your CPS representation does not include explicit exception continuations. <mark_weaver>how do you do the equivalent of checking that the exception continuations are the same? <wingo>our exceptions are dynamic, but any given "normal" continuation has the same dynamic environment <wingo>because the popping of a prompt is part of normal control flow <wingo>so checking that the normal continuation is the same is sufficient to test that the dynamic environment is the same <wingo>to elide a prompt in CPS you have to simulate the dynamic env <wingo>for example if you can prove that the tag is the same, then you can map an abort to a handler <wingo>but you will have to insert a node to pop the prompt before continuing to the handler <mark_weaver>okay, time for me sleep. (past time, really :) good night all! <jmd>I'm looking for a procedure like format, but which returns the result, instead of shoving it to a port. Is there such an animal? <wingo>pass #f as the port to format <jmd>One of the pleasures of programming with guile, is that #guile usually provides an answer painlessly. <jmd>Whereas #perl first tells you what an ignorant peasant you are, to RTFM and not to waste their time with silly questions. Only if you first drop your pants might you get an answer. <ft>To be fair, that kind of reply usually comes with increased size of a channel. :) <jmd>In guile 1.8.7 : How can I easily find out where an ERROR is comming from ? <janneke>jmd: what kind of error; set a breakpoint on scm_error? <jmd>ERROR: Wrong type (expecting pair): () ***ijp`` is now known as ijp
<jmd>(or (* 2 b) (not (* 2 b))) <civodul>bipt: i get a segfault on "make check" in guile-emacs from Git/master <civodul>i'm unable to get a useful backtrace though <jave>im unable to build guile-emacs atm. <jave>last working build was on the 14th <wingo>bipt left 4 minutes before you came in <jave>i have a ci server pointing at bipts repo, so i suppose it will solve itself eventually *dsmith-work is starting on a new project at work, a windows kernel driver. <nalaginrut>mark_weaver: BTW, do you know a guy named Doven? <nalaginrut>alright I typed it correctly but modified to wrong... <mark_weaver>yeah, I know him. I saw him a lot around the MIT AI lab when I hung out there. <nalaginrut>yes he lives in Hong Kong, and he come to shenzhen to play open hardware <mark_weaver>he had been hanging out there for a very long time, long before me. <nalaginrut>and show me his doomclock, which is made with arduino <nalaginrut>wow, so he is real, anyway I just can't believe that in the beginning <nalaginrut>and he called Greenblatt to wake up then open his computer ;-) <mark_weaver>heh. yeah, Devon has a lot of connections around MIT. <nalaginrut>well, then we decide to say "hell o" from now on, rather than "hello" <nalaginrut>actually it's a LEDs controller, and could be easily controlled with SVG <nalaginrut>then I suggest him to use my Artanis for server side to download the firmware to arduino automatically <mark_weaver>yeah, all the hard bits are already implemented in free software. <nalaginrut>yes! that's why open hardware is very popular nowadays <nalaginrut>it's all of our community guys thought, include designer and hardware hackers <mark_weaver>indeed, I shudder to think what the world would be like without the extraordinary efforts of RMS and free software hackers around the world. <nalaginrut>anyway, we can hardly call this fashion "hardware renaissence" as Paul Graham said, I'll call it "hardware uprising under free software" ;=) <mark_weaver>without free software, I think I would not be using computers at all, and would be one of those grumpy old men who eschew all modern technology as evil :) <mark_weaver>playing guitar badly at the side of the road for a few coins :) <nalaginrut>when I was a poor student, I try to study hard to learn computer, they give me VisualStudio and tell me buy <<learn C++ in 21 days>> *taylanub has had (very) slight considerations of concentrating on an instrument and doing music for a living instead of software, would probably have more time for *free* and actually useful software that way. :P <nalaginrut>fortunately I met a guy who introduce SICP to me, and free software <mark_weaver>nalaginrut: Vast numbers of promising CS students have been ruined by early exposure to C++. I'm glad you avoided that fate. <nalaginrut>the real cool thing is, with free software, I can learn the things by myself <nalaginrut>mark_weaver: when I start to use GNU, there're lot of language to choose, but on windows, I have VC only ;-P <nalaginrut>if I use windows, I inclined to watch movie or play games, but under GNU/Linux, I could calm down and hacking <nalaginrut>I think windows is a good thing for entertainment, in spite of free <nalaginrut>there's only Linux on my machine, maybe months later, there'd be Hurd <nalaginrut>I can live with GNU, it's real, but when I met GNU first time, it's a dream <nalaginrut>nowadays, expert on GNU/Linux and GNU tools/apps means high paid work in China <mark_weaver>when enough people share the same dream, it can become reality <mark_weaver>The leaders of China are smart to avoid dependency on western-controlled technology. <nalaginrut>well, it's unbelievable, however it's a pure dream, people do real work with Windows <nalaginrut>mark_weaver: the bad side is people in China incline to copy, or modified some free software then claimed it's their original work <nalaginrut>in spite of epic, it would be a nightmare for Chinese tech area, there'll be price for that <nalaginrut>with good things, we should consider how to make better things <mark_weaver>nalaginrut: I understood two out of those last four messages. What do you mean by "in spite of epic" and "stay and lazy" ? <nalaginrut>I mean comfort with other guys work, and lazy to make it better <mark_weaver>people do a lot of very bad things to get more money. <mark_weaver>I must say, although taking credit for the work of others is bad, there are many worse things that people resort to. <nalaginrut>free software brings huge money and opportunities, so people changed <mark_weaver>if that was the worst evil that people did in the world, life would be pretty nice :) <nalaginrut>yes, anyway I'm too pessimistic， there're lot of guys do right things <nalaginrut>I'm not criticizing, I just anxious about it, it's a big chance to study, or it'd be price to pay <nalaginrut>mark_weaver: it's too late for me ,see you next day <shanecelis>mark_weaver: I did something, and I feel the need for approval or dissuasion. In Emacsy, I want to export interactive commands from a module, such that the user can include only commands from a MODULE_PATH like a bash PATH. <shanecelis>mark_weaver: So I followed the pattern for public interfaces that modules. Instead of 'resolve-interface' and 'export', I have 'resolve-command-interface' and 'export-command'. Objections? <shanecelis>mark_weaver: BTW, thank you for the enhanced make-trampoline procedure. I'm using it in my code now and very happy with it. <davexunit>shanecelis: what benefit do you get from it? <ijp>.oO(I sometimes think I'm the only person in the scheme world that hates trampolines) <ijp>funny fact, I used to be able to do back flips on a trampoline...until I learned to do front flips. Since then, never landed one again. <fds>ijp: What's the better alternative? (We're talking about implementing tail call optimisation, right?) <ijp>fds: not using C functions, and being able to goto directly <shanecelis>davexunit: The application benefit is being able to expose commands more selectively to the user. Allows buffers and the minibuffer to hopefully expose appropriate commands. <ijp>the original argument for TCO was that it _is_ an optimisation <fds>Oh, I see. What about C functions stops this? <ijp>once you start doing trampolines, you've made it slower than an old "expensive" function call <fds>I mean, which property. <ijp>fds: the C calling convention <shanecelis>ijp: True. The reason I'm using them is when/if the user updates the function, it will then use the updated function, not the old procedure. However, the user doesn't have to use a trampoline if they don't want. <davexunit>shanecelis: ohhhh yeah I do that in my program as well. <davexunit>so I can redefine my update, draw, etc. procedures and have the relevant hooks call the updated procedure. <shanecelis>davexunit: Yeah, I adopted this as my convention: (define-key map (kbd "A") 'some-proc) -> (define-key map (kbd "A") (lambda () (some-proc)) <shanecelis>So the user can still provide the straight procedure, no trampoline if they like, but if they provide a symbol, it makes a trampoline for them. <davexunit>I want to provide the same thing for guile-2d <shanecelis>haha, I want to steal your coroutines and scheduler, and you want my kbd. There are synergies here. :) <shanecelis> (make-trampoline module name) (let ((var (module-variable module <wingo>surely it would be better to use a macro? but whatever :) <davexunit>so the way this works is that you specify that module and procedure name? <wingo>(define-syntax-rule (make-trampoline module name) (lambda () ((@@ module name)))) <shanecelis>Yeah, but I'm trying to keep it Emacs-like, so I want: (define-key map (kbd "A") 'some-proc) -> (define-key map (kbd "A") (lambda () (some-proc)) whereas if they say (define-key map (kbd "A") some-proc) it'll just bind directly to that procedure. <davexunit>wouldn't a more scheme way be to not use a symbol in the first place though? <davexunit>define-key would end up being a macro, though. <ijp>doing lexical scoping right means names shouldn't matter <shanecelis>Exactly, define-key would become a macro, and then you're forcing trampolines, and possibly precluding some uses. <mark_weaver>I agree that using a macro would be better. The only reason I gave the solution I did is because shanecelis specified that he was starting with a _symbol_. <davexunit>define-key takes a symbol and calls make-trampoline with it, right? <mark_weaver>indeed, it's worth investigating if you could avoid starting with a symbol. <shanecelis>davexunit: If the user provides a symbol, a trampoline is used. If not, it's whatever the user specified. <davexunit>you want to avoid the user having to explicitly trampoline things? <davexunit>can you think of a case where you would *not* want trampolines? <shanecelis>Well, wouldn't any anonymous procedure not work with this macro? <mark_weaver>an anonymous procedure wouldn't work with the code I gave you either. <mark_weaver>the macro expects a 'name'. it expands to (@@ module name), and that syntax expects 'name' to be a single identifier. <shanecelis>I think the trampoline is a good pattern for interactive development that Emacsy and guile-2d propose, but (lambda () (name)) looks like noise. Emacs can get away with just providing the symbol because there is no module system. Providing a symbol is syntactic sugar. <shanecelis>mark_weaver: Right, which is why define-key only makes a trampoline if it's given a symbol not a procedure. <davexunit>mark_weaver: oh yeah well if we're going to keep with the module access thing then you're right. it won't work. <ijp>the module system isn't why emacs can get away with it <ijp>it's because symbols have a function slot <ijp>the indirection is baked into function evaluation <mark_weaver>shanecelis: regarding the 'export-command' thing... hmm. sounds a bit fishy to me, but I don't have any clear thoughts on the matter right now. maybe ask civodul? <shanecelis>mark_weaver: Ok. Will do. Yeah, I'm not sure either. <mark_weaver>I'd be reluctant to add more complexity to the module system. <davexunit>ijp: do you mean because emacs uses funcall? <mark_weaver>an important idea in Scheme is that everything is in a single namespace. <mark_weaver>(though if you haven't yet Tolkien you might not get it :) <mark_weaver>of course, that was before Scheme had macros. oh well. still something to strive for though. <mark_weaver>this is not specific to elisp. it has long been part of lisp. scheme cleaned this up, and many other things. <ijp>davexunit: funcall is a symptom, not the cause <mark_weaver>well, maybe better to say that scheme "simplified this". some people might prefer the lisp way, and that would not be entirely unreasonable, though I'm firmly in the scheme camp :) <mark_weaver>the lisp way certainly make higher-order programming more awkward. ***shader` is now known as shader
<ijp>do we have a convenient way of programmatically only importing a subset of bindings from (foo) into module (bar) ? <ijp>i.e. what the #:select in use-modules does, but from outside the module <ijp>actual use case is to use modules as plug-ins, but with some magic method names for setup/teardown/etc. ***ijp` is now known as ijp
<ijp>wingo: ah, that looks like it <civodul>i think the videos will soon be on-line <shanecelis>civodul: I'm writing up an email to guile-user with an Emacsy design question that I threw at Mark. <ijp>hmm, I thought #:hide was what I wanted, but it is (rightly) strict <ijp>ijpbot: shoot aidalgol <ijp>ijpbot: shoot aidalgol <ijpbot>Wrong type argument in position 1 (expecting pair): #() <ijp>ijpbot: shoot aidalgol *ijpbot loads its hose and drenchess aidalgol <ijp>aidalgol: I knocked up a quick "plugin" interface, so that commands could go in separate modules <ijp>I've just pushed, you can look on the plugins branch *sneek looks squinty-eyed at ijpbot *sneek moves into the catbot stance <aidalgol>ijp: wth is the for-each thing in run-cbot.scm doing ? <add^_>aidalgol: I think it is dsmith.. <aidalgol>Yeah, that sounds about right... I think I knew this a while ago. <aidalgol>Does ijp have control over sneek, as well? <civodul>mark_weaver: wingo & you have been doing a great job! *ijpbot loads its shotgun and blastss add^_ *mark_weaver loads his EMP weapon and blasts ijpbot *ijpbot loads its hose and drenchess ijpbot <add^_>ijpbot: shoot nobody-is-having-this-nick *ijpbot loads its hose and drenchess nobody-is-having-this-nick <aidalgol>No, it's probably appending 's' to the verb. <ijp>aidalgol: registering commands <mark_weaver>hmm, I have some old scheme code lying around that's pretty good at building up english sentences, including making things plural properly and all the weird rules. <mark_weaver>I wrote similar code for french as well, but I'm less confident that it does the right thing. <civodul>mark_weaver: even just looking at (language cps) makes me feel that much time has passed since tree-il.scm et al. were written <mark_weaver>I never looked at compile-glil, and from wingo's recent email I think I'm glad I won't have to now :) *ijpbot loads its hose and drenches ijp <ijp>it would probably make more sense as a for-each over an alist, rather than two parallel lists