RE: Immutable names of things?

[Sean Corfield]

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, yo

Re: Immutable names of things?

[John Newman]

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  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  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 

Re: Immutable names of things?

[John Newman]

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  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 

Re: Immutable names of things?

[Didier]

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 

Re: Immutable names of things?

[Eric Normand]

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 

Re: Immutable names of things?

[Jozef Wagner]

I think it's a great idea and it may even be a missing piece in the 'Grow, 
not Break' approach https://youtu.be/oyLBGkS5ICk?t=1946 , namely to the 
problem that good names are hard to come by. 

Suppose a library author wants to make a breaking change to some function. 
They change the doc-name of the 'old' function to e.g. foo-old, and reuse 
foo for the new 'version' of the function. Existing code using this library 
would work as before, but in the sources the visible name would 
automagically update to the `foo-old`, thus informing developers that 
there's a new/better flavor of foo available. This is IMO a far better 
approach then inventing new names like new-foo, foo2, or my.ns2/foo, for 
functions that are meant to succeed their legacy variants.

Jozef

On Thursday, December 7, 2017 at 6:37:10 AM UTC+1, 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 

Re: Immutable names of things?

[Chas Emerick]

No, this is an excellent idea.

Joe Armstrong is probably the most notable modern figure to have written 
and talked about making code content-addressable, with chunks of code (I 
forget the granularity he proposed, probably top-levels?) having names as 
metadata. IIRC, first at https://www.youtube.com/watch?v=lKXe3HUG2l4, then 
here: https://joearms.github.io/published/2015-03-12-The_web_of_names.html

There have been a variety of very niche programming tools that implement 
some variant of this (a single authoritative identifier for a patch of code 
or verse or other data structure, with display names being assigned and 
manipulated separately), but this brings us to the key passage in your 
message IMO:

> The problem is I'm not sure how to do this with a text based programming 
language

And here's the rub: no scheme like this will work or scale in the 80xN grid 
to which we've confined ourselves. That's IMO of course; I'll save you from 
opining further, I guess. :-)

Projectional / structural editors are absolutely a thing though, so you'll 
find a lot if you search along those terms. A dedicated (but quiet) 
subreddit actually popped up on the topic not too long ago:

https://www.reddit.com/r/nosyntax/

Have fun,

- Chas

On Thursday, December 7, 2017 at 12:37:10 AM UTC-5, 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, 

Immutable names of things?

[Didier]

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.