convore.json/groups/arc-runtime-project/getting-critical-changes-into-ar/messages.json

[{"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306414042.160897, "message": "I uh, kinda did a lotta stuff on my fork, which is okay, but then I kinda dumped it all on you at once, which isn't so okay. And some of my changes would be controversial, I'm sure.\n\nSo here's my plan. I'm going to create a branch on my fork, which is pulled from ar, so it's nice and clean, no changes. Then, I'll sift through my changes and pull out the *really* important ones that I think absolutely should go into ar. Then we can worry about merging those changes into base ar.\n\nMy first priority is to get something like defcall, since in my mind any Arc implementation that doesn't have the equivalent of defcall is weak and broken. To accomplish that, here's my plan: first off, move coerce and + into Arc, since I think that'll be pretty easy to do. Then, add in an ar-not-fn function, which just throws an error.\n\nWhen ar-apply sees something that's not an fn, it will call ar-not-fn. This should let Arc extend/change/replace ar-not-fn to get defcall behavior. Then, in Arc, I can overwrite ar-not-fn so it calls coerce, and also change coerce so it uses tables, that way it can be broken up into smaller functions, and it'll make it a lot easier to add in coerce rules, since you no longer need to extend coerce itself as much.\n\nI'm not entirely convinced about the name \"ar-not-fn\", so if you have any suggestions, that'd be great, but I figure even if the name isn't perfect, better to run with it and we can change it later.", "group_id": 9739, "id": 1191437}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306414381.0867889, "message": "(And when I said \"broken\" I meant \"inflexible, rigid, not Arc-like\", in the same way I might call Python's lambdas \"broken\", because dammit I want to be able to say, \"when you see this thing in functional position, do this\")", "group_id": 9739, "id": 1191496}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1306424049.7846379, "message": "\"ar-call\"?", "group_id": 9739, "id": 1193131}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1306425927.556813, "message": "\"ar-call-other\"?", "group_id": 9739, "id": 1193469}, {"user_id": 32943, "stars": [], "topic_id": 36891, "date_created": 1306425819.157557, "message": "In my predicate dispatch pursuits with Lathe and Penknife, I've had a base utility that took care of the default cases and another one that could be extended. (But then I have failcall, so it's easy to recover if an extension doesn't exist....) I tend to call the extend-me utility the same thing as the regular one but with -rb appended to the end to signify that it's a rulebook. I don't know how common these things would be in ar, but maybe a suffix like -custom or -ex could make sense.", "group_id": 9739, "id": 1193448}, {"user_id": 32943, "stars": [], "topic_id": 36891, "date_created": 1306426172.6676531, "message": "\"My first priority is to get something like defcall, since in my mind any Arc implementation that doesn't have the equivalent of defcall is weak and broken.\"\n\nI agree with that. ^^ Still, I haven't actually taken much advantage of defcall thanks to its lack of cross-implementation support. It's only in Anarki and Rainbow, and they're not consistent with each other.", "group_id": 9739, "id": 1193500}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306540433.8266301, "message": "What about \"ar-call-fail\"?", "group_id": 9739, "id": 1210040}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306541167.9173961, "message": "@rocketnia By the way, this is a little off-topic, but what are the differences between Anarki's defcall and Rainbow's defcall?", "group_id": 9739, "id": 1210110}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1306597908.3307991, "message": "\"ar-call-non-fn\"", "group_id": 9739, "id": 1212928}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306646407.284174, "message": "By the way, aw, you can basically ignore my pull request for now, until I've sorted some stuff out.", "group_id": 9739, "id": 1216176}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306646653.1946111, "message": "Sorry again for the gigantic changeset.", "group_id": 9739, "id": 1216180}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1306650981.1716299, "message": "ok", "group_id": 9739, "id": 1216319}, {"user_id": 32943, "stars": [], "topic_id": 36891, "date_created": 1306663800.9124329, "message": "Primarily, I think Anarki 'defcall passes the called value to the function as the first parameter, whereas Rainbow 'defcall passes the 'rep of the value. Also, Rainbow doesn't even support coercion to 'fn (which the Anarki version of 'defcall revolves around); I think it's based on a version of 'defcall from back when Anarki was still on Arc 2.", "group_id": 9739, "id": 1216670}, {"user_id": 32943, "stars": [], "topic_id": 36891, "date_created": 1306663902.9906559, "message": "Anarki:\narc> (defcall foo (a b c) (list a b c))\n#<procedure>\narc> ((annotate 'foo 'woo) 1 2)\n(#(tagged foo woo) 1 2)\n\nRainbow:\narc> (defcall foo (a b c) (list a b c))\n(fn (a b c) (list a b c))\narc> ((annotate 'foo 'woo) 1 2)\n(woo 1 2)", "group_id": 9739, "id": 1216672}, {"user_id": 32943, "stars": [], "topic_id": 36891, "date_created": 1306664288.0792179, "message": "Editorializing: I prefer Anarki's semantics because sometimes I'd want to pass the value off to some other utility without first unwrapping it with 'rep. And as you might expect, I really don't care about the 'coerce stuff one way or another. I'd actually prefer to use (extend ar-call-non-fn ...) or whatever instead of 'defcall, so that I could also extend cases that didn't correspond with types per se.", "group_id": 9739, "id": 1216693}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306704318.3542659, "message": "In case you're curious, my idea is that defcall would work only on the type, but it would basically be using ar-call-non-fn.\n\nSo (defcall foo ...) would be like (extend ar-call-non-fn (x ...) (isa x 'foo) ...) except that defcall can be implemented faster. So yeah, basically, defcall would be a faster and more convenient way to \"extend\" ar-call-non-fn.", "group_id": 9739, "id": 1220601}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306704510.249881, "message": "So, yeah, sure, use extend when you want to dispatch on something other than the type, but I'd recommend defcall when you want to dispatch on the type, because it's shorter, cleaner, more readable, and faster.\n\nOf course, knowing you, you'd probably prefer to use something other than type, isa, and coerce anyways. :P", "group_id": 9739, "id": 1220623}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306703992.5483739, "message": "(Personally, I've given up on the coerce-to-fn idea, so I'm still going to have defcall, but it'll be using a different mechanism. If anybody wants to add in coerce-to-fn, go ahead, but I think I have a better idea)", "group_id": 9739, "id": 1220564}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306704058.7365799, "message": "Also, I agree with you that it probably shouldn't automatically unwrap the value. Of course, if we implemented waterhouse's idea of having everything unwrapped automatically, then sure, but since pretty much nothing else unwraps, why should defcall be an exception?", "group_id": 9739, "id": 1220575}, {"user_id": 32943, "stars": [], "topic_id": 36891, "date_created": 1306708343.017113, "message": "\"So (defcall foo ...) would be like (extend ar-call-non-fn (x ...) (isa x 'foo) ...)...\"\n\nThat's what I was thinking too. ^_^ I figure there should be one extension to ar-call-non-fn which looks up the type in a table. This makes it so that if you enter (defcall foo ...) on the REPL and then you realize it was buggy, you can paste in a fixed version and it automatically overwrites the old one. An older version of aw's 'extend had labels for just that kind of purpose (and Lathe's 'extend is based on that one!), and it might be something worth putting in, but for something like 'defcall the label is obvious: It's the type.", "group_id": 9739, "id": 1221104}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306709159.086751, "message": "Eeeexactly, that's what I was thinking.", "group_id": 9739, "id": 1221262}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1306962247.28863, "message": "@Pauan just curious since it's been a few days since you said you wanted to, are you still planning to push changes to ar?", "group_id": 9739, "id": 1258616}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306965280.8859911, "message": "Yes. I was waiting for the ail merge, since I knew you were working on that. I've also been messing around with objects, slices, and import, but that should hopefully be wrapped up soon.", "group_id": 9739, "id": 1259240}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1306993850.0635369, "message": "Alright, I'm finally ready to get started on defcall. I've updated my master branch to point to normal ar, so I can slowly start pushing my changes out, rather than doing it all in one go.", "group_id": 9739, "id": 1263474}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307000760.2382929, "message": "(I'll note that it might be better to move it to ac.arc, but we can do that later. First priority is getting it working)", "group_id": 9739, "id": 1264179}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307000246.850528, "message": "Aha! I think I got a good solution. I ended up defining defcall in ar.ail, simply because a lot of things depend on hash tables and strings being callable... it's actually not that bad. The most verbose part is the lack of \"iflet\", but I think it's still shorter than it is in ar right now.", "group_id": 9739, "id": 1264148}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307000474.288017, "message": "Okay, nevermind, it's longer. :P The defcall for tables is shorter, but the extra infrastructure for ar-call-non-fn and defcall make it longer in the end. That's okay, though, since defcall is important and it's about the same size as it would be in arc.arc anyways.", "group_id": 9739, "id": 1264166}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307063809.713021, "message": "Okay, great, now my next priority is to get my Python-style unit tests into ar. That okay with you, aw?", "group_id": 9739, "id": 1273320}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307064647.2254529, "message": "By the way, this would be a good time to ask. How do you feel about putting libraries into the ar repo? For instance, I was hoping to get import.arc and object.arc into ar, but as libraries in the lib/ subdirectory. That way, they're available for people who want to use them, but if you don't want them, you don't have to load them. So, yes? No?", "group_id": 9739, "id": 1273408}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307064029.245836, "message": "Not sure, I haven't looked at your tests yet, should I look at your \"old\" branch?", "group_id": 9739, "id": 1273343}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307063997.840589, "message": "(Note: that'll mean adding in lib/re.arc, lib/tester.arc, a tests/ subdirectory, a bunch of unit tests that I have written, and also converting the existing Arc tests to use the tester library)", "group_id": 9739, "id": 1273339}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307064036.618341, "message": "I've already converted arc.t (on my fork) to use my library, so the process of porting shouldn't be too hard.", "group_id": 9739, "id": 1273346}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307063944.597271, "message": "oops, I had to revert, tests are broken.  I can fix it up though and resubmit.", "group_id": 9739, "id": 1273333}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307064080.821604, "message": "ok", "group_id": 9739, "id": 1273354}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307064063.1329329, "message": "And yes, it's in the old branch, in the tests/ subdirectory.", "group_id": 9739, "id": 1273350}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307072319.3715041, "message": "hmm, I see another issue... ideally ar-call-non-fn could be extended or overridden in Arc, but it's being passed a Racket list", "group_id": 9739, "id": 1274152}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307072388.7358069, "message": "oh, which is true of the old ar-apply-cons etc. as well", "group_id": 9739, "id": 1274159}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307073115.308569, "message": "Alright, but what if I later decide to change tester.arc so it uses import.arc to isolate each test file? I was actually planning on such a change, but haven't done it just yet.", "group_id": 9739, "id": 1274222}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307071948.7025261, "message": "Hmm, as a way to get libraries available to people who want to use them, I imagine it would probably be a poor choice for most situations.  Suppose I put your library in ar, and then I make an \"improvement\" to it that I think is a great idea and insist upon but you don't like.  Now you have to publish your own version anyway, but people are used to looking for your library in the ar repository instead of in your repository.  Or, you have some useful or important change to make to your library, but I don't have time to work on ar myself for a few weeks, so you're sitting around waiting for me to push the \"merge\" button instead of being able to instantly publish your better version yourself.\n\nI think it would probably be a lot more scalable if we instead had a list of libraries that worked with ar and where to get them.", "group_id": 9739, "id": 1274124}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307073665.0641961, "message": "On including libraries in ar, maybe a situation where you would want to do that is if you have something which is tightly bound to the internals of ar.  defcall is a good example: the code is \"how to implement defcall in ar\" as opposed to a e.g. a library that would run in any Arc implementation.", "group_id": 9739, "id": 1274278}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307073432.354866, "message": "Ah, okay.", "group_id": 9739, "id": 1274256}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307073190.686975, "message": "As for ar-call-non-fn, I'll get that working too, along with fixing it to use something other than ar-toarc. What should it use, by the way?", "group_id": 9739, "id": 1274229}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307073333.2693169, "message": "I'm working on ar-call-non-fn now", "group_id": 9739, "id": 1274246}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307073639.838908, "message": "Hm... that's a good point. Well, for now, I guess my *real* question is: would you accept using my Python-style unit test library in ar, until we find a good way to separate tests someplace else?", "group_id": 9739, "id": 1274275}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307073485.6610811, "message": "Right, the current \"equal-wrt-testing.arc\" and \"test.arc\" don't actually belong in ar either, they're just there because it would be too much of a pain to use them from somewhere else without more infrastructure in place.", "group_id": 9739, "id": 1274258}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307073765.7366731, "message": "Still need to look at them... probably will be tomorrow at this point.", "group_id": 9739, "id": 1274292}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307073827.516331, "message": "Alrighty then. I guess I'll cook up something else to do in the meantime.", "group_id": 9739, "id": 1274300}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307074474.9999239, "message": "The only tricky part is that we can't *call* \"call-types*\" in the defrule test because that leads to an infinite loop, so we have to use racket-hash-ref.", "group_id": 9739, "id": 1274382}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307074402.85816, "message": "ok, I took another stab at defcall... now ar-call-non-fn takes an Arc list for its args argument, so there's no difficulty extending it from Arc.  And call-types* and the defcall implementation is now in defcall.arc as a library.", "group_id": 9739, "id": 1274372}, {"user_id": 32943, "stars": [], "topic_id": 36891, "date_created": 1307079840.1008971, "message": "What about putting a special-cased (defrule ar-apply-non-fn (isa x 'table) ...) after the 'call-types* rule so that it's tried first and intervenes in the loop? I'm not saying this option is any more elegant than the one you've got, but it is an option. Take from it what you will. ^_^", "group_id": 9739, "id": 1274958}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307082848.770643, "message": "(I would also recommend having it bind orig, since that's very useful, and I've had plenty of times where I've wanted that behavior)", "group_id": 9739, "id": 1275230}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307082438.947295, "message": "Actually, I don't see why you can't just call it... you already have ar-call-non-fn set up in ar.ail, so calling should work just fine.", "group_id": 9739, "id": 1275200}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307082646.5143771, "message": "(I'll note that if you changed defrule so it binded orig, then you could use that)", "group_id": 9739, "id": 1275213}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307082554.5847521, "message": "(If it didn't, then Arc wouldn't work at all, since it actually *relies* on hashes and strings being callable)", "group_id": 9739, "id": 1275206}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307114429.9798679, "message": "@Pauan \"Actually, I don't see why you can't just call it\"\n\nwhat is the \"it\"?  call-types*?  If you mean you think you can call call-types* in the test for how to call call-types*, try it for yourself ^^", "group_id": 9739, "id": 1278246}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307115989.140882, "message": "re having defrule bind orig: the issue there is I routinely remove code that isn't being used.  So if I remove orig from defrule, and all the tests pass, then I say \"aha, good, that wasn't used anywhere\".  So what would be helpful is some illustrative examples and tests of how people find binding orig useful.  Then the functionality at least won't get deleted by accident...", "group_id": 9739, "id": 1278413}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307115608.2625699, "message": "@Pauan re using Python style tests: yes, I like them.  The syntax should eventually be integrated into Arc (loadable as a library, naturally) so that the test files can be loaded from Arc... but that can be a longer term project.  I would recommend having a syntax for expressions evaluated for their side-effect when we don't care about their return value (\"(mac achtung (x) `(+ ,x 2))\", for example); that would make those tests both shorter and more clear.", "group_id": 9739, "id": 1278368}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307151384.9082191, "message": "^^", "group_id": 9739, "id": 1283780}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307151346.7406449, "message": "Yeah, I realized *after* I posted that it would cause an infinite loop, due to the lack of orig.", "group_id": 9739, "id": 1283775}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307151985.8646209, "message": "Not so. Because defrule can expand into extend. If it were a library, then it *would* be redundant, because we would have almost-identical code twice.", "group_id": 9739, "id": 1283882}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307152393.174087, "message": "ok, from the perspective of factoring defrule into smaller parts to reduce code duplication in code using ar, that makes sense", "group_id": 9739, "id": 1283933}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307151616.925106, "message": "\"So what would be helpful is some illustrative examples and tests of how people find binding orig useful.\"\n\nI already have some tests written that rely on orig being bound, and I can easily write some more. Also, I think ar should have extend, and then defrule can expand into a call to extend.\n\nWhy? Well, defrule is shorter, but I dislike it because A) I need to look up the argument signature rather than just using my own, and B) if the function's argument signature changes, then my defrule breaks. So I think people should have a choice whether to use the more-reliable extend, or the less verbose defrule.", "group_id": 9739, "id": 1283805}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307151811.1161859, "message": "it's fine to have extend as a library, but not going to use in ar because it would be redundant", "group_id": 9739, "id": 1283849}, {"user_id": 25438, "stars": [], "topic_id": 36891, "date_created": 1307152152.0124841, "message": "that might make sense", "group_id": 9739, "id": 1283903}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307151488.391139, "message": "Okay, great, and the tester already *is* a library, and the test files already *can* be loaded from Arc, so I got you covered. In fact, the way to run tests is to call the \"run-tests\" file, which is an Arc executable.\n\nAs for expressions that don't have a side effect, yeah, Python already has that ability, and I should be able to add that in. I also had an idea about one-line tests: \">>> foo -> bar\" would mean that foo should evaluate to bar. But I'm not sure about the syntax...", "group_id": 9739, "id": 1283789}, {"user_id": 32737, "stars": [], "topic_id": 36891, "date_created": 1307152036.7782719, "message": "(On the other hand, having defrule as a library would make sense, because defrule can use extend, but extend can't use defrule)", "group_id": 9739, "id": 1283887}]