<jmd>Somebody sent me a guile fragment where strings were compared with 'string=' I've never seen that before. I tthought equal? was the thing. <ijp>well, there are stricter versions of equality that check types <ijp>though I forget the difference between string= and string=? <ijp>oh right, string= let's you specify subranges ***ceverett is now known as zxq9
<dsmith>ijp, WHat is it about that you don't like? <ijp>people walk away with the idea that these are somehow good macros to write <ijp>when really it a lot of it is creative abuse <micro__>ijp what would you recommend as a good macro primer? <ijp>dybvigs syntax-case introduction is okay <ijp>but if it's syntax-rules you are after, it's kind of transparent isn't it? <ijp>(define-syntax-rule (foo bar) (baz quux zot)) <ijp>see (foo bar) replace with (baz quux zot). simple. <micro__>mechanics are ok - it's 'proper'application <micro__>there's lots of talk abot macros being abused (as your point concerning define-syntax-primer.txt) <ijp>the rule of thumb is, if you think you need a macro, you are almost certainly wrong <ijp>you won't, no-one ever does <ijp>it seems to be one of those lessons you learn the hard way <ijp>I wouldn't go that far <ijp>just plain old "everyone thinks they are special" <ijp>the thing about macros is that they infect your code, and beget more macros <micro__>do you have an example of code where macros are used judiciously? <ijp>What did you do? What did you get? What did you expect? What are you running? etc.etc. <shanecelis>Maybe this is the correct behavior. If it were strings, I'd probably expect similar behavior. <ijp>well, you aren't allowed to mutate literals <ijp>I think we give errors for that in strings now <fbs>seems to work fine in .9 <shanecelis>I think doing similarly for typed array literals would be good. <ijp>doesn't happen here either <fbs>#f64(1.0 1.0 2.0)#f64(0.0 1.0 2.0)s <shanecelis>This makes me wish I hadn't patched guile to allow for a reader macro that emits no symbols (I needed #line pragmas). <wingo>i guess reader macros are the way to do that <wingo>shanecelis: yes so those arrays are literals and thus may share storage <wingo>we don't currently signal an error on mutation, but we should <wingo>i think we will be able to do so in 2.2 <lloda`>+1 for we should, those are nasty errors <wingo>we could do so in 2.0 with additional flags, but there's no space for those flags in pairs, and you would want to catch the pair case <wingo>in 2.2, most memory is read-only and thus can be mprotected, and we can do the segfault dance to signal an error <davexunit>is there a document anywhere that says what features 2.2 will bring? <wingo>not really -- it's mostly the new vm that doesn't have anythign central written about it <ijp>it will smite the heads of our enemies <wingo>there are a number of cleanups but those aren't interesting <wingo>i hope to write about the vm soon, now that it's almost finished <wingo>it's quite a bit faster and should have better memory usage <wingo>and is an important step on the path to native compilation <wingo>it's kindof a slog but some points are exciting, yes :) <davexunit>as a bystander it's exciting. I can only imagine the challenging problems that need to be solved. <davexunit>I don't know how much technical debt guile has. <wingo>it has some, but not as much as it used to <wingo>would be nice if we could use a generational gc at some point, but i'm not sure we will be able to <davexunit>I find myself fighting with the gc when writing a "realtime" application <davexunit>but that's a problem with any gc'd programming language. <wingo>probably, yes; though the rust people seem to be having a good time reasoning about gc with types <davexunit>the common technique to avoid gc runs is using pools, but sometimes that's hard to do. <wingo>isolates sound interesting, like what the dart people do <wingo>anyway, lots of fun things :) <wingo>in the end you always have to tune for good performance, even with C++ <davexunit>yeah, imo my biggest issue that I've encountered so far is dealing with lots of floating point operations in Guile. <davexunit>because of reasons you and mark_weaver have explained in the past. <wingo>yep, need to do better in that regard <wingo>there is quite a road to walk before we can have good fp performace <wingo>basically we need native compilation, and ideally adaptive compilation like what v8 does ***sethalve_ is now known as sethalves
*civodul needs to look into all this <wingo>or if not we'll talk at ELS :) *wingo still doesn't have the hang of french holidays :) <civodul>yeah i guess i'll have to get an update from you at ELS <wingo>i think i'm going to rebase wip-rtl to a new branch and start merging trivial patches to master and submitting larger ones to guile-devel <wingo>i'll send some mails first with some perspective