FWIW, this was a bit like the approach taken in Expectations – functions were given names based on a hash of the code in the test, meaning that old functions (tests) stayed around if you change the tests (which created a newly named function). This led to problems with REPL usage since you could not tell which was a “live” function as opposed to an old one. Consequently, if you had a bad test and fixed it, the old test was still around and would still fail when you tried to “run all tests”.
Just offering this as a data point for problems that can be caused for tooling with this sort of approach… Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ________________________________ From: clojure@googlegroups.com <clojure@googlegroups.com> on behalf of Eric Normand <ericwnorm...@gmail.com> Sent: Monday, December 11, 2017 4:12:37 PM To: Clojure Subject: Re: Immutable names of things? Hi Didier, Are you familiar with Unison (http://unisonweb.org/)? It has this same feature. Functions are named by a hash of their code (the AST). Names refer to hashes. So if you want to recompile a function, you can optionally choose newer versions of all of the functions. But changing a function's code does not make the old version go away. Other functions compiled against the old versions will still use the old versions. It basically pushes the version control down to the function level instead of the whole project. The effect was that you could have a dynamically-recompiled language experience without breaking anything that was already compiled. You could redefine everything about a function (it's type signature, it's code, etc) but existing stuff would keep working. Then when the function was to your liking, you could recompile everything to use the new version. Eric On Wednesday, December 6, 2017 at 11:37:10 PM UTC-6, Didier wrote: Warning: This is the spawn of an idea, not very well refined, and that is little extravagant. I've been doing some hammock time, and I've been thinking that names in a programming language are kind of a complecting of two things, the human readable form, and the machine identifier. What if a function always had the same name, which never changed, from the moment the function was created. This would be fine, until a human finds it didn't like the name anymore, and thus a refactor of the name would occur, requiring to change all references to the function. This is also true say of a spec, if you want to change the name of the spec, its a big refactor to update all usage of it. So var names and spec names are troubling in that if humans want to refer to it differently, they also break all machine reference to them. So I thought, how awesome would it be if each named things in a programming language would be given a unique machine name, which can be used everywhere, and the name you saw was just meta-data for the programmer to have a more human readable/descriptive name. The problem is I'm not sure how to do this with a text based programming language. I can imagine a language where constructs would be first class, not based on text, and thus all construct could be assigned a unique id and a name, and the IDEs could easily hide the unique ids and project a view of the construct with the human name instead. Code would be stored in a structured format, and obviously a standard editor would not work, and an IDE of some form would be required. So right now, my idea is that maybe you can compromise. If you added support for Vars and specs, so that they can have like a doc-name. It would be like a doc-string a bit, but it expects a name instead. That name could be the human readable name, you could change it freely. The normal var name or spec name would continue to be used as normal to refer to this var/spec from other code. At its most basic it means you can have the normal name be anything, maybe a name you don't like that much, or you could go further and make it a guid if you want. Then you could make the doc-name the name you want to use when talking to other people, or when people read the code. Now IDEs could support this doc-name, so they could show the doc-name in place everywhere you have code referring to the normal name. They could auto-complete from doc-name to normal name, etc. So an IDE could still kind of hide this for you, and make it appear like everything is just doc-name pointing to each other, and refactoring would not require changing all code that refers to it, but actually its just a change of the doc-name on the var or spec being pointed to, but the IDE could quickly replace the new doc-name in place of the normal name everywhere else. Where it would be maybe a bit more confusing, is when using an editor that would not support doc-names to that extent. In those cases, you can ignore doc-name, consider it just like one more piece of documentation. Doc-name could be optional too, so if you plan on working by yourself, or just in a simple editor, you can ignore this whole thing and work as normal. Now maybe this whole thing is solved by having a powerful renaming refactoring tool that can hunt for all usage and update the name everywhere in a sound way, but that's harder to do in Clojure, and still breaks when its a library for example, as you can't just refactor all consumers without having both access to their code base, and even if you do, its tedious to pull down everything in your desktop and set it up for such a refactor. I'd be interested in thoughts about this, even if its just, that sounds like a terrible idea :p. Thanks. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com<mailto:clojure+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
