What if the code segments were hashed by zipper coordinates instead of line-column location? I like this idea of structurally navigating the code as an AST of EDN :)
John On Mon, Dec 11, 2017 at 7:55 PM, John Newman <john...@gmail.com> wrote: > This might be a step towards a more clojury way: http://blog.datomic.com/ > 2012/10/codeq.html > > John > > On Mon, Dec 11, 2017 at 7:53 PM, Didier <didi...@gmail.com> wrote: > >> I'll have a look at all these other projects, its very interesting. >> Unison seems to embody the spirit or Richs talk about never changing >> anything too. I guess I was trying to think how could you bring some of >> this to Clojure. And in a way, if the constructs like functions had an id >> and a name, you could start building out things like that more so. Which is >> where I thought about the potential of considering the existing name as an >> id, and having something else for naming the construct. >> >> I guess, if I think about it some more, Clojure could save its code as >> the AST straight up using EDN. Someone could build an IDE on top of that, >> which never allows you to change the text, but only works directly at the >> EDN level with the clojure code as data. It would be a lot of work, but >> possible I think. >> >> >> On Monday, 11 December 2017 16:12:37 UTC-8, Eric Normand wrote: >>> >>> 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. >> 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.
