convore.json/groups/arc-runtime-project/coercing-nil-to-cons/messages.json

[{"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305174319.5800321, "message": "Shouldn't (coerce nil 'cons) return nil?", "group_id": 9739, "id": 1019632}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305174793.503315, "message": "Kay, I'll add that in, then.", "group_id": 9739, "id": 1019694}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305174764.056123, "message": "It doesn't in Arc 3.1, though it probably should.", "group_id": 9739, "id": 1019686}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305177052.132602, "message": "P.S. I think (coerce 123 'num) should actually return a number. I also think it should print as 123.0 rather than 123, to make it obvious that it is, indeed, a num. But that's for a different topic.", "group_id": 9739, "id": 1020106}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305177179.4286389, "message": "Though doing something sensible with the int/num distinction isn't a bad idea.", "group_id": 9739, "id": 1020128}, {"user_id": 22796, "stars": [], "topic_id": 34893, "date_created": 1305176163.505444, "message": "I experimented with this a while back, but this thread convinced me to make it throw an error: http://arclanguage.org/item?id=12646", "group_id": 9739, "id": 1019881}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305177224.4642241, "message": "Hm... why does mod require an int? Shouldn't (mod 5.5 3) return 2.5?", "group_id": 9739, "id": 1020136}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305176674.27019, "message": "arc> (type (coerce 123 'num))\nint\n", "group_id": 9739, "id": 1020024}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305176549.6782601, "message": "The change is super easy to revert if we ever change our minds, by the way.", "group_id": 9739, "id": 1020003}, {"user_id": 22796, "stars": [], "topic_id": 34893, "date_created": 1305176214.136785, "message": "Hmm, now I reread it it's not very clear why an error is better. Just a vague fear of making coerce sometimes not return the type you're coercing to.", "group_id": 9739, "id": 1019892}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305176727.5336671, "message": "I don't know if that's right or not, but it's not a invariant that we currently have.", "group_id": 9739, "id": 1020035}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305176536.1226411, "message": "Well, the way I see it, nil serves both as a symbol, boolean false, and the empty list. So in a sense, it's three types at once. Thus, in the same way that (coerce nil 'sym) returns nil, I think it makes sense for (coerce nil 'cons) to return nil too.\n\nI suppose one objection to this change is that you can't set the car or cdr of nil, but you can set them for every other cons. As far as I know, that's the only difference between nil and other conses.", "group_id": 9739, "id": 1020000}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305176672.637872, "message": "In Arc 3.1 coerce doesn't always return the type that you coerce into.", "group_id": 9739, "id": 1020023}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305176764.4094751, "message": "Sure, but don't int and nums have the same interface? Meaning every function that expects an int can also work with a num? But every function that works on a cons doesn't work on nil: scar and scdr.", "group_id": 9739, "id": 1020044}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305177418.8270869, "message": "I'll note that from a practical perspective, it's not a big deal right now, simply because A) we're not using coerce much, B) we're a small group, and C) we tend to muck around with stuff, rather than write production-ready airtight programs.", "group_id": 9739, "id": 1020176}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305177139.7215149, "message": "My only point was that I didn't think we needed to worry about coerce returning the exact type that we're coercing to.  But, while I don't think it matters, it's not true that every function that expects an int can also work with a num...:", "group_id": 9739, "id": 1020124}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305177141.373071, "message": "arc> (even 2.5)\nError: \"modulo: expects type <integer> as 1st argument, given: 2.5; other arguments were: 2\"\n", "group_id": 9739, "id": 1020125}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305177346.5981901, "message": "Well, I agree with you that we shouldn't *require* that coerce *always* returns whatever you requested, but I think it's useful for it to be consistent about it as much as reasonable.", "group_id": 9739, "id": 1020158}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305177442.9566791, "message": "But *eventually* it would be nice to give coerce sane, airtight semantics. If it's reasonable to do so.", "group_id": 9739, "id": 1020179}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305178647.0518961, "message": "I've spent my entire life writing and fixing bugs in production programs, and I can't imagine what difference it would make. Not once have I ever looked at a production problem and said \"gosh, if only this language had strictly disjoint types, life would be so much better\".  I certainly have no objection to improving the semantics of type and coerce, but to argue that it makes Arc \"production-ready\" or not strikes me as rather silly.", "group_id": 9739, "id": 1020458}, {"user_id": 22796, "stars": [], "topic_id": 34893, "date_created": 1305180886.46229, "message": "awwx: I see (I'm catching up on this thread). Makes sense. I think I just want to feel sure that nil will never cause an error because a cons was expected. Can you think of any case where arc/racket throws an error for () but not for other lists?", "group_id": 9739, "id": 1020888}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305209390.325531, "message": "arc> (apply / nil)\nError: \"/: expects at least 1 argument, given 0\"\n", "group_id": 9739, "id": 1024749}, {"user_id": 22796, "stars": [], "topic_id": 34893, "date_created": 1305213742.899755, "message": "thanks :) I suppose that could trigger when expanding a macro, but it doesn't seem very likely", "group_id": 9739, "id": 1025470}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305221859.9593649, "message": "Not that you all aren't well aware of my take on this, but I think the best way to give 'coerce a sane, airtight semantics is to ditch it in favor of individual functions for each target \"type.\" Rather than [coerce _ 'cons], I'd use listify._, etc. Just thought I'd chime in. ^^", "group_id": 9739, "id": 1026740}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305235432.2305291, "message": "Except that's not any different. Not that your way doesn't have benefits, mind you. I agree that having those functions as *conveniences* is useful, especially since you can then use ssyntax: listify.foo or listify:foo but that's all they are: conveniences.\n\nSo you're still left with the same problems: what does listify do when given nil? So I don't see how replacing (coerce foo 'cons) with (listify foo) will solve that problem. Care to explain?\n\nUnless you're saying that \"listify\" would be more equivalent to (coerce foo 'list) and thus have different semantics than (coerce foo 'cons), which is a reasonable thing to do, but listify can just be a wrapper:\n\n(def listify (x)\n  (if (no x) x\n             (coerce x 'cons)))", "group_id": 9739, "id": 1030172}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305236326.6874149, "message": "\"but to argue that it makes Arc \"production-ready\" or not strikes me as rather silly.\"\n\nSure, I was pointing out the reasons why I think we think it's not a big deal. And perhaps you're right and it wouldn't be a big deal even in production programs either. I do think mod should accept nums, though, regardless of what we do with coerce.", "group_id": 9739, "id": 1030300}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305243169.8992181, "message": "As for what you said... hm... I'm not sure. It's true that you can define one in terms of the other. I'll give it some thought about which should be the default.", "group_id": 9739, "id": 1031303}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305242976.4945199, "message": "\"So you're still left with the same problems: what does listify do when given nil?\"\n\nSince nil is a list, 'listify could happily return nil. I'm not sure what else you expect it to do.\n\nIf things like 'listify were in the language, 'coerce could be a wrapper:\n\n(def coerce (x to) (case to string string.x int int.x table tableify.x fn fnify.x ...))\n\nBut what good would this wrapper be? It wouldn't be any more convenient, and you end up with the dilemma of whether to design [coerce _ 'cons] to use 'listify or to use something which only returns things of type 'cons. Adding 'coerce creates a wart.", "group_id": 9739, "id": 1031289}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305243101.2980249, "message": "And by the way, (coerce \"\" 'cons) returns nil. I'm surprised that (coerce nil 'cons) raises an error.", "group_id": 9739, "id": 1031294}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305243120.7368259, "message": "(in Arc 3.1)", "group_id": 9739, "id": 1031296}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305243124.6142581, "message": "That's why I fixed it. (coerce nil 'cons) works on my fork.", "group_id": 9739, "id": 1031297}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305243549.5181789, "message": "By the way, I can think of one area where coerce is more convenient than a bunch of wrappers. I was thinking about in Arubic, with function parameters. Remember how we talked about moving destructuring to quote, so we can add nifty stuff like (= foo ...)?\n\nWell, I figured I could add in a rule that says, when (coerce ...) appears in the argument list, it will try to coerce the variable when the function is evaluated. Which means that this:\n\n(fn (a b (coerce c 'int)) ...)\n\nIs equivalent to this:\n\n(fn (a b c) (= c (coerce c 'int)) ...)\n\nAnd then I could use ssyntax to make it pretty:\n\n(fn (a b c:int) ...)\n\nIt's possible with things like list? cons? etc. but I think it would be easier and cleaner to do it with coerce.", "group_id": 9739, "id": 1031327}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305245505.3417051, "message": "Why not have this:\n\n(fn (a b (zap int c)) ...)\n\nBe equivalent to this:\n\n(fn (a b c) (zap int c) ...)\n\nThis (zap int c) already has the same effect as (= c (coerce c 'int)).", "group_id": 9739, "id": 1031517}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305245595.197252, "message": "Hmm... actually, that sounds like a better idea, thanks! More general, too.", "group_id": 9739, "id": 1031521}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305245792.1187699, "message": "And then, how about this ssyntax?\n\n(fn (a b c->int) ...)\n\nI see one problem with that, though. Calling (table foo) doesn't coerce it to a table, it creates a new table. We can change that, though. In any case, we can experiment later, it's not final or anything.", "group_id": 9739, "id": 1031547}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305249300.182081, "message": "\"(fn (a b (zap int c)) ...)\"  don't forget this will conflict with list destructuring.", "group_id": 9739, "id": 1032051}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305249472.8971491, "message": "No, it won't. Maybe you didn't see the thread, but rocketnia and I already fixed that a while ago. List destructuring in Arubic will use quote: (fn (a b '(c d e)) ...)", "group_id": 9739, "id": 1032079}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305249607.0632191, "message": "And I also had the idea of using quasiquote as well, so you could selectively evaluate things: (fn (a b `(c ,d->int e))) Neat, huh?", "group_id": 9739, "id": 1032111}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305299855.72803, "message": "FWIW, I want to mention that (fn (a b (.zap int c)) ...) is still an option for people who don't like the quote for destructuring. I could go either way.", "group_id": 9739, "id": 1042823}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305318946.5449989, "message": "No, rocketnia, we've gone over this. :P Ssyntax will be handled at the reader level, so that trick won't work.", "group_id": 9739, "id": 1046984}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305319300.4865129, "message": "(Though I suppose you could define prefix . to expand into a special gensym, then that trick could work, but honestly I think I'll go the quote-for-destructuring route)", "group_id": 9739, "id": 1047038}, {"user_id": 32737, "stars": [], "topic_id": 34893, "date_created": 1305326149.1903441, "message": "Ah, right, well that's fine, but we *were* discussing Arubic, after all. If you want to implement zap using the .zap trick in normal Arc, go ahead. :P", "group_id": 9739, "id": 1048305}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305326031.437047, "message": "Sheesh, do I have to qualify everything? :-p The (fn (a b (.zap int c)) ...) approach is an option for *my* hacks on ar, not necessarily yours. ;)", "group_id": 9739, "id": 1048295}, {"user_id": 32943, "stars": [], "topic_id": 34893, "date_created": 1305326444.199069, "message": "I'm open to other hypothetical languages where (fn (a b (zap int c)) ...) \"will conflict with list destructuring\" or there are \"people who don't like the quote for destructuring\"...", "group_id": 9739, "id": 1048328}, {"user_id": 25438, "stars": [], "topic_id": 34893, "date_created": 1305398939.9065461, "message": "(coerce nil 'cons) now returns nil, thanks to Pauan's patch.", "group_id": 9739, "id": 1054075}]