<sneek>ijp, davexunit says: that was amazing <davexunit>I need to learn how to switch windows, so far I just have emacs open and that's it. ***sneek_ is now known as sneek
<davexunit>it runs and I was able to start emacs and a web browser. <b4283>cool, another lisp wm after stumpwm <davexunit>guile-wm has the advantage of being written in a lisp that I much prefer. :) <davexunit>figuring out clisp vs sbcl and other issues with stumpwm was frustrating. <b4283>yes, never been able to compile stumpwm <davexunit>and it is super easy to jump into guile-wm's repl <davexunit>just added a new command, bound it to a key, and it just worked. *nalaginrut want to try Wayland <davexunit>it would probably take some work to abstract the underlying window server out. <u_l-lap>aaaand bpt has yet to start working on guile-emacs again despite it being break >:O <u_l-lap>a few folks made some majorly invasive changes that are kind of stupid (e.g. replacing 0/1 returns with true/false constants) and much rebasing now will be needed due to inaction, yech <u_l-lap>and of course the only current copy is on a single laptop :( <u_l-lap>bipt: push your changes even if they aren't in perfect form damnit <u_l-lap>bipt: imagine if your laptop lights on fire or you are in a car crash <u_l-lap>with emacs25 frozen, the time to prepare for guile-emacs is NOW <u_l-lap>no better time to merge a huge change into trunk than right after they fork the release branch IMO <u_l-lap>otherwise, there's the risk that guile-emacs won't land for another 5+ years in the form of emacs27 :( <davexunit>I have a feeling that it's not going to make it in. <u_l-lap>so maybe still time for emacs25 to be guile emacs <u_l-lap>** The second argument of `eval' can now specify a lexical environment. <u_l-lap>kind of like guile's very evil eval in local environment thing <taylanub>u_l-lap: Re. 0/1 -> false/true, you mean the C code ? That should be a very simple rebase, I imagine. <taylanub>u_l-lap: Are you sure it's 25 that's frozen, and not 24.4 ? <u_l-lap>now, rebase when you've removed most of those functions <taylanub>u_l-lap: Oh sorry, didn't read all you wrote. <u_l-lap>still, bipt needs to push those damned patches! <taylanub>Hrm, that wouldn't be bad, but will you contribute ? ;) <u_l-lap>even if it would be as a gigantic "you're a fool if you don't expect this branch to die very soon", so others can test emacs using the guile elisp compiler instead of the elisp interpreter <u_l-lap>I might ... it'd be a neat project to get OpenGL contexts via figl working in emacs buffers <u_l-lap>I need to poke wigs and get my figl stuff merged <u_l-lap>and also rename his hcoop account, probably ought to do that first ... kind of bad when I'm slacking on a member support request by working on his project <u_l-lap>but graphics hacks are so much more fun to write than boring sysadmin things are to do! <taylanub>u_l-lap: Re. "guile's very evil eval in local environment thing", what is that ? I can't find it in (info "(guile) Fly Evaluation"). Was it a pre-2.0 thing ? <u_l-lap>it is less evil than I remember it being in 1.x, you at least can't use `define' <taylanub>Why exactly is it evil ? Trying to think of static-analysis related stuff but my mind isn't fully awake yet :P <u_l-lap>the current form isn't that evil from the looks of it. You used to be able to modify the lexical environment, which is ... not very lexical <u_l-lap>I think it inhibits some potential optimizations, but since you have to capture (the-environment) at least it would only cost things that used it <ijp>taylanub: (define (foo f) (let ((bar baz)) (f))) (foo (lambda () (eval 'bar))) <ijp>now, for double evil points (define foo bar) (define (baz f) (f) foo) (baz (lambda () (eval '(define foo veeblefetzer))))) <taylanub>ijp: But `local-eval' requires an enviroment arg <ijp>did you want working code, or a high level idea? <ijp>fundamentally, lexical scope means names don't matter <taylanub>I said that because I think it invalidates your example, but I'm taking a closer look ... <taylanub>ijp: Definitions don't work at all in `local-eval' BTW. <ijp>yes, which unknown lamer already said <ijp>fundamentally, a local eval is an abstraction leakage <ijp>(the same can be said of open modules, but if you want a dynamic environment, you can't not do that) <taylanub>OK, (define (foo f) (let ((bar baz)) (f (the-environment)))) (foo (lambda (e) (local-eval 'bar e))) is the working version <ijp>no definitions, plus opt-in means the current form is basically neutered, and so it is not more evil than eval <taylanub>OK, we could say that having the value returned by `the-environment' escape the lexical environment means we have the possibility of "invisible code" so to say, IOW static analysis becomes entirely(???) pointless. <taylanub>"Entirely pointless" is probably an exaggeration, but as an immediate practical example, `set!' could be called on anything without our static analyzer seeing it. <taylanub>I'm trying to figure out what core feature makes `local-eval' implementable, to get a better idea on implications on static analysis ... <ijp>various psyntax related hackery <taylanub>Using ,expand on it gives some insane output. :( <ijp>*presumably* it wraps the variable in a magic box, with the appropriate symbol binding in the created module <taylanub>No idea what that means, probably because I'm a psyntax noob. <ijp>(disclaimer: I have not read the source) <ijp>with identifier syntax, this is probably not difficult to do <taylanub>,expand outputs about 300 LOC for every variable in the lexical env. >_< ***DerGuteM1ritz is now known as DerGuteMoritz
<davexunit>I'm trying to write a macro that expands to 1 of 2 possible forms depending on the result of a predicate. <taylanub>davexunit: Will need to be an imperative one I guess, i.e. use `syntax-case'. <taylanub>(It might or might not be possible to bend `syntax-rules' to your will, but it probably won't be pretty. :P) *davexunit goes to read about syntax-case <davexunit>I can't quite figure out how to use syntax-case <taylanub>Lemme write a small example with annotations explaining what's going on, maybe it can help <taylanub>(Remove ?scheme part from URI to remove line numbers, for copying.) *taylanub saves that for future use. <davexunit>what does the underscore mean in a syntax pattern? <taylanub>Just like in `syntax-rules', it doesn't matter what's in the first position since that will always be the name of the syntax form (i.e. `test' in this case). And otherwise it's a wildcard that matches anything (standardized in R7RS-small (maybe R6RS too), supported by Guile and most implementations already AFAIK). <taylanub>No problem. I never used `syntax-case' in practice yet myself so it's good to remind myself how to use it every once in a while. :P <davexunit>I'm trying to write a macro that behaves differently depending on if a top-level variable is defined or not <taylanub>Hrm, that's very non-idiomatic I think, but the module API should do I guess. <davexunit>maybe there's a better way to do it, but I have what I think is a good reason for such behavior. <davexunit>I'm writing a simple module for functional reactive programming. <davexunit>and working at the REPL is a big part of this library. <davexunit>with FRP, you declare the relationships between values that change over time. <davexunit>I could have something like: (define 2mouse-x (signal-map (cut * <> 2) mouse-x)) <davexunit>and 2mouse-x will *always* be twice the current value of mouse-x at the present time. <davexunit>to do this, the 2mouse-x signal registers itself as an output on mouse-x. <davexunit>now, imagine that I'm working from a REPL and I realize that 2mouse-x is actually not doing what I want it to do. I want to be able to re-define it and have the previous value of 2mouse-x unregister itself. <davexunit>I hope that this makes some amount of sense. <davexunit>basically, there's a dependency tree being built and I want to be able to re-define part of it and have it take the place of the old value <davexunit>by removing the old dependency and inserting the new one in its place. <davexunit>without this behavior, I can still work from the REPL fine (sort of), but I'm essentially leaking memory and performing computations that are never actually used anywhere. <davexunit>additionally, if other signals depend on 2mouse-x and I re-define 2mouse-x, then of course those other signals are still using the previously bound value. <davexunit>I'm writing a signal-splice! procedure that can do the necessary surgery.