[swift-evolution] [Idea]Why not get dynamically named variables?

[David Sweeris]

That's far more interesting than lasagna recipes :-)

More abstractly, if I understand correctly, you want to write some code, which in turn will — at runtime — write its own code, *and* said code should have the ability to interact with the already-written code. Does that sound like an accurate summarization?

If so, I *think* what you're asking for can, in effect, already be accomplished by restructuring your code (if necessary), requiring a swift toolchain to be installed (already done if this is for a personal project), and using the dylib mechanisms to compile and call the "2nd generation" code at runtime.

The part I'm unsure of is how to make a module map for the "1st-gen" code to link to when the module doesn't actually exist yet... If you're on macOS*, it might be easy(er) to write a "discovery" API layer in Obj-C which exploits its dynamism to pass the details on the "2nd-gen" code back to Swift land. I'd imagine it'd all have to be done with a ton of generics programming and a library containing all the protocols, base classes, and such that the two code bases would need to talk to each other (at least it could be a normal, run-of-the-mill statically linked library).

I kinda hope I'm missing something and there's more to it than that, though. I find your idea quite intriguing, and I'd be a little bit disappointed if it turned out that something as "out there" as dynamically-named variables could be effectively, if not literally, reduced to just a DLL and some compiler trickery.

- Dave Sweeris

*I know there's something about Obj-C interoperability that's very specifically only part of the Apple ecosystem and isn't part of open-source Swift, but I can't remember what it is.

Sent from my iPhone

> On Sep 4, 2016, at 11:43, Fayez Hellani <fayez.hellani at icloud.com> wrote:
> 
> And btw, the idea behind this, as you said, isn't for normal programming, it’s for AI, and helping the app think by itself, so that it could create variables and constants easily, on its own, when it needs all that. 
>> On Sep 4, 2016, at 9:33 PM, David Sweeris <davesweeris at mac.com> wrote:
>> 
>> 
>>> On Sep 4, 2016, at 10:28, Fayez Hellani via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Hey! There should be an option to name variables AND constants dynamically. For e.g. in an app from storing recipes, where the user creates a recipe,the recipe should be stored in a constant (as a structure) with a name “\(TitleTextField.text)_Recipe” (e.g. “Lasagna_Recipe”), so that it gets stored easily and therefore fetched even easier.
>> 
>> I'm not sure I understand... Are you suggesting we be allowed to declare a variable like this?
>>  var foo = "bar"
>>  var \(foo) = 42 //is really named `bar`
>> 
>> If so, how do we then interact with it? Having to write
>>  \(foo) *= 3
>> doesn't seem any better than
>>  bar *= 3
>> Plus, string interpolation could get real tricky to read if someone nests the naming redirections, so to speak, too deep.
>> 
>> At least for "normal" programming, I don't think I get it...
>> 
>> Outside of that, I wonder if this idea might be part of a conceptual basis for some sort of fusion between interpreted code and complied code, or maybe part of the fabled macro system.
>> 
>> - Dave Sweeris
>