convore.json/groups/arc-runtime-project/rename-acons-to-cons/messages.json

[{"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305050250.9718771, "message": "And possibly have \"acons\" be an alias for backwards compatibility?", "group_id": 9739, "id": 993648}, {"user_id": 25438, "stars": [], "topic_id": 34594, "date_created": 1305054883.8357019, "message": "Here's my thoughts on naming:\n\nSo far Arc has been consistent with not using \"?\" for predicates, but it hasn't been very consistent for what it *does* use for predicates: if there's already a function with predicate name, then Arc uses an \"a\" prefix: \"acons\", \"alist\"; but if there isn't then Arc uses no prefix or suffix: \"number\", \"letter\", \"digit\", etc.\n\nI think that coming up with better names is a good thing to do, especially if it's done globally so that we get a consistent naming convention.\n\nI don't think that maintaining backwards compatibility is a good idea.  It adds extra complexity to the system without any way of knowing whether anyone actually needs it.\n\nI also don't think that it's the role of ar to be choosing a *particular* naming convention, but it is very much the role of ar to *support* people coming up with naming conventions.  For example, we could have one \"Arc 3.1\" library that we load in ar which provides strictly Arc 3.1 names, and another library which provides an Arc variant with has a better naming convention.", "group_id": 9739, "id": 994648}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305055205.6165299, "message": "Of course. Hence why I mentioned the alias idea. We could have an \"arc3.1.arc\" file that would smooth over some differences, including creating acons as an alias.\n\nThat way, if you load up arc3.1.arc you get Arc/pg semantics and names, which is nice because then we can load up libraries that were written for Arc/pg, while still breaking backwards compat in \"normal\" ar.\n\nThis could even be done on a case-by-case basis, only putting stuff into arc3.1.arc when it actually breaks a library that you want to use.", "group_id": 9739, "id": 994739}, {"user_id": 25438, "stars": [], "topic_id": 34594, "date_created": 1305055316.5662251, "message": "Hmm, another thought about libraries built on ar.  In the Linux kernel, people can choose to either write their device drivers outside of the kernel tree or to have their driver included in the kernel tree.  The advantage of having a driver included in the kernel tree is that when the driver API is changed, all the drivers in the kernel tree are modified to continue to work with the new API.\n\nBy analogy, a library built upon ar could either be maintained outside of ar or it could be included in the ar git repository.  An advantage of having a library in the ar repository is that as changes are made to ar, the included libraries would be (should be) updated so that they still work.\n\nFor this to work, the included library would need to have enough unit tests so that someone changing ar would be able to tell if the library was still working.", "group_id": 9739, "id": 994772}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305238445.3003139, "message": "By the way, my thoughts for the naming conventions for predicates is as follows: if the predicate takes a single argument, it should *usually* put ? at the end, otherwise it shouldn't. So \"is\" remains \"is\", \"isa\" remains \"isa\", etc. but \"acons\" becomes \"cons?\" and \"alist\" becomes \"list?\"\n\nMy reasoning is that you should be able to replace (foo? bar) with \"is bar (a) foo?\". This also means that \"no\" should remain as \"no\", because \"is bar no?\" doesn't make grammatical sense.\n\nBy the way, I want to change \"no\" to \"not\". I keep getting confused when I read/write code, because \"no\" already means something in English, and that something is different from logical not. Whereas \"not\" more unambiguously refers to logical negation. It's only one character more, but I think it would provide more consistency with \"and\" and \"or\".", "group_id": 9739, "id": 1030653}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305243988.9280889, "message": "(But empty will probably be changing to use the ? convention: (if empty?.elements ...))", "group_id": 9739, "id": 1031359}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305243957.436774, "message": "(Maybe we should have both \"no\" and \"not\" by default? Though you could also use empty: (if empty.elements ...))", "group_id": 9739, "id": 1031357}, {"user_id": 32943, "stars": [], "topic_id": 34594, "date_created": 1305243502.0403571, "message": "I like saying (if no.elements ...) from time to time (whenever I can't use 'unless), so I like 'no the way it is.\n\nMeanwhile, I agree wholeheartedly with your foo? conventions, but I'm concerned (too concerned?) that we'll lose a good ssyntax character that way.", "group_id": 9739, "id": 1031324}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305243730.2828791, "message": "So... even if \"no\" is clunky and confusing 90% of the time, you would prefer to keep it that way? By the way, there will be a backcompat.arc file, that makes \"no\" an alias for \"not\", so if you load that file, you can use both. So this is more about the default in ar.\n\nSsyntax is (will be) split into prefix, infix, and suffix. We would only lose suffix ? but we could still use infix ? and prefix ?", "group_id": 9739, "id": 1031339}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305244561.3276081, "message": "Oh! I just had an idea! What if suffix ? expanded into coerce? So \"list?\" would be equivalent to \"(fn (x) (coerce x 'list))\"", "group_id": 9739, "id": 1031412}, {"user_id": 32943, "stars": [], "topic_id": 34594, "date_created": 1305246207.1995549, "message": "\"No\" is actually mnemonic though. I remember hearing that pg named things according to the shortest thing that would remind someone of a behavior they already knew about, rather than trying to describe the whole behavior in a long name. I think that's a good guideline, and \"no\" reminds me of nothing but nil and [is _ nil].", "group_id": 9739, "id": 1031607}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305244617.6834531, "message": "Not sure whether that's actually a good idea or not, but just putting it out there.", "group_id": 9739, "id": 1031420}, {"user_id": 32943, "stars": [], "topic_id": 34594, "date_created": 1305245827.0743711, "message": "I hardly see how \"no\" be more clunky and confusing than \"not.\" It has fewer characters! :)", "group_id": 9739, "id": 1031552}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305245911.0876639, "message": "Yes! In fact, let's create an APL/Lisp hybrid. Even fewer characters! Or maybe MUMPS...", "group_id": 9739, "id": 1031571}, {"user_id": 32943, "stars": [], "topic_id": 34594, "date_created": 1305246251.4195049, "message": "And possibly reminds me of 'empty. :-p", "group_id": 9739, "id": 1031611}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305246332.4384489, "message": "The problem is that when I see \"no\" I think the English \"no\". Whereas \"not\" is closer to the actual definition of \"no\" in Arc.\n\nIf the English \"no\" were closer to logical not, then it probably wouldn't be a problem.", "group_id": 9739, "id": 1031617}, {"user_id": 32737, "stars": [], "topic_id": 34594, "date_created": 1305246404.6757209, "message": "\"1. (a negative used to express dissent, denial, or refusal, as in response to a question or request)\"\n\nThat uh, that isn't what \"no\" means in Arc. Sorry, I have a LOT more experience speaking/reading English than I do Arc, so my brain still thinks of the English \"no\" when I see \"no\".", "group_id": 9739, "id": 1031620}]