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.
