You could capitalize the F... ![]()
As I've gotten more comfortable with flexing the power of virtual binding (e.g. the error propagation operator picking up the contextual definition of return)...I'm actually thinking that the way that leading-dot works is to implicitly connect to this, which you could even just name a local definition that:
add2x3x+1: enclose add/ this -> [
.value1: .value1 * 2
.value2: .value2 * 3
1 + eval this
]
If we wanted to be more semiotic about it, then it could be .
add2x3x+1: enclose add/ . -> [
.value1: .value1 * 2
.value2: .value2 * 3
1 + eval .
]
I just think:
-
that's too hard to see
-
..value1is illegal (currently and maybe forever, though technically it could be a TUPLE! with two leading SPACE runes)- so you'd have to write
(.).value1for an equivalent, and it just feel weird to not be able to say simply.foois a synonym forthis.foo
- so you'd have to write
-
.probably has better uses as some as-yet-thought-of operator, or even left free to user local definition
But anyway... back to the topic... I don't think the ^ has a "good" value-add here if just talking about visibility, if the user experience can be legitimately de-complicated.
If nothing worse than what I've found so far comes up, I think on balance having those cases be written as (foo.bar: lift x) would be a reasonable tradeoff.
Note that I'm coming at this from being deep in the implementation and realizing what a debacle the "moment of unlifting" in function bodies is. Defining that moment, dealing with type-checking on lifted vs. unlifted forms... losing the "this cell has been typechecked bit" by the auto-unlift to bring down the representation of non-^META arguments... the tax on tail calls re-entering a function that's already had its locals unlifted and what to do about that, etc. etc.
I really think that being able to copy and paste code out of the inside of a function and put it into an ADAPT as-is has material value, and not having these ^ for cases that don't "need" it has material value. So it's very much worth pursuing.
Will it work? I'll see. But I do like to write things up to see what problems I can spot before trying things. On occasion that turns out to waste time vs. "just trying it and seeing what immediate failures happen"... but the scale of this change is so large that "just trying it" will take some time.