Taking type inference to next level : Variable without declaration

[Xyncgas]

Let variables be usable without being declared

Consider

let mutable x = new ClassA()
x <- x.Increment()///A member function

let y = x
let z = y.Increment()

printfn "%A" z

what if we can use x without declaring x, what if we can use y without declaring y, imagine

printfn "%A" y.Increment()
//automatically creates a variable called y = new ClassA()

z.MakeRequest()
//automatically use y, since ClassA immutable

it's possible, if a variable has not been declare before then you can use it as if it's already declared, and if a variable should refer to a mutable object you have to do that manually, otherwise if you already created something immutable, the variable you just used directly represents all the stuffs you created previously, referencing to those immutable objects, giving people a good experience in the editor too by letting intellisense to look at what's available after '.'

[Happypig375]

Have fun with typos and easy-to-make bugs

[SchlenkR]

First of all, thank you for the idea presented here. It may be that it seems a little immature and that the sense and purpose are not really clear. I say: Never mind! It is only an idea and I consider it legitimate to put it up for discussion. One way is to accept such things as a thought experiment without judging it right away. I try it once:

I can just as well imagine (as @Happypig375 has already mentioned) that there will be a problem with practicability, since any typo of an identifier would automatically turn into the shown kind of "later-scoped-identifiers". This could be countered by the programmer expressing his intention that it is something "late-scoped". As an example, I define a syntax, namely a & preceding the identifier, e.g.:

module A =
    let inline names = &xs |> List.map (fun x -> x.Name) |> String.concat ", "

In the example xs is not present in the lexical scope, which would normally be an error. The & prefix could e.g. indicate that an identifier xs must be in the (lexical?) scope if it is used. xs would be (at least partially) unknown until names would actually be used somewhere. Thereby already statements can be made concerning xs, e.g.:

• It must be a 'a list.
• 'a must have a property or field name of type string.

Type inference would have to be structural for such "late-scoped" expressions and would have to be "parcial", because in the end it can only be solved if the whole expression is actually used.

Usage and inlining:

As I understand the idea, it goes like this, "There is a piece of code that is incompletely described with respect to the identifiers that are in scope, which can only gain completeness when it is used". Is that roughly how it is meant? If it is meant that way, such pieces of code that have a template character would have to be instantiated by inlining. Example:

module B =
    type Person = { name: string; age: int }
    let xs = 
        [ 
            { name = "Josef"; age = 55 }
            { name = "Harald"; age = 61 }
        ]
    
    // `A.names` is basically a template that (finally) gets instanciated by inlining
    let personNames = A.names

As I said, whether this is a "good" or "bad" thing, I haven't thought about it. It certainly seems a bit "exotic" to me, and I have a hard time imagining it fitting the explicitness and clarity of F#. Still, I'm not sure if there might be domain-specific languages that would be more expressive of such a concept. It's certainly interesting to see what tooling could be provided to make features of this sort more usable by the user. Personally and generally, I like the idea of a language that relies heavily on structural constraints and keeps multiple inference solutions open as long as possible, but communicates this to the user through tooling (and also makes it's final decisions clear by communicating language/type inference to the user through good tooling).

Have a nice evening, and thanks again.

[ShalokShalom]

I dont know how I feel about language features, that heavily rely on tooling.

Tooling is supposed to be a help, that is optional.

Not key requirement to productively use the language 🤔

[SchlenkR]

That's one valid point of view, and that's propably the case for the majority of textual programming languages, although...

• I've never used Kotlin, which I'm curious of because it's made by a tooling company
• I guess I couldn't do my work without relying heavily on tooling, which is VS (C# + ReSharper, F#), VSCode (TypeScript, F# + Ionide), etc. Turning off ReSharper because of performance reasons? No! ;)

I find it beneficial to invalidate those things from time to time and challenge known problems again. So, turning the last 2 statements upside down:

Tooling is supposed to be a help, and it's a key requirement to productively use the language!

Why not?

For graphical languages, tooling is required in the cases I know, and it's an interesting field because tooling is thought from the beginning, and it's a key point for selling those things. The graphical programming environments that I know are special purpose products, where it's about simulation, signal processing, etc.: Max/MSP, NI Reaktor, Matlab/Simulink.

[ShalokShalom]

I think that languages usually start to rely on tooling, since the implemention of the language feature is lacking and tooling is supposed to fix that.

Take Java, as an example. Super fancy tooling, and you need that, since moving around in your code is literally impossible otherwise, at least in larger codebases.

And I am not saying all tooling is bad, but that using it to cover half baked ideas, who got implemented anyway, seems like a bad idea.

And if the first thing you come up with, to cover a concern of a possible implementation, is immediately to use some sort of tooling, that inherently leaves the language itself with said weakness.

In graphical languages, the tooling and the language are one and the same, and their usage is taken into account as one in the first place.

I think that only shows, that you have to be extra careful to design a graphical language without covering one of it's flaws accidentally with a crux, and I thats also what makes them so difficult.

The whole logic of a feature should be self containing, and not be dependent on some external tool, that fixes one of it's mistakes.

I think if we look at old languages, and what their biggest flaws are, we can see more often than not, that they are literally unusable without the appropriate tooling, right at that place and center.

On the other side, Smalltalk (Pharo) is a perfect example of how tooling can be optional, and still fancy and super useful.

I would still like to code with the IDE, and I dont need it.

Having said all this, I still see no reason why this should be nessecarily the case here, as I dont see why tooling would be per se needed in this proposal.

There are probably other reasons, who might speak against it, though.

[Xyncgas]

I would be happy to entertain again and again, because the conversations are interesting

As I understand the idea, it goes like this, "There is a piece of code that is incompletely described with respect to the identifiers that are in scope, which can only gain completeness when it is used". Is that roughly how it is meant?

I shall be starting by saying imagine :

randChar.NextInt64()

It means, despite I had never declared a variable named randChar , it should be referring to something that has a member called NextInt64. If at the end of the day, instance of such a type exists and is immutable we can reuse it by referring randChar to it, though objects can be constructed with different constructor and have different state despite being the same type so maybe some way to provide the constructor eventually while in the same breath functions in module should be alright... I am starting to wonder if it might be a dump idea but the cat is out of the bag have fun

Another point I can make is, inferring types based on usage would let us provide parameter names in function without saying its type explicitly like in C#, randChar would be constrained by its usage when you pass it to some function, which ultimately determines its actual type if there's multiple qualifying types which implements .NextInt64() and error on it is not

it can let people write shorter code, it can let people potentially reuse variable names :

let a = x.NextInt64() //now x is one of those types that has a member NextInt64
let b = x.Fetch() //now x is one of those types that has a member Fetch

Also the idea is everything is code even typos and gibberish is appealing too, basically :

fewl kewi8.q odie

this is a valid program
If it does what you want, it feels good to write
I don't know how, but deep down I know it's possible and the structure of the code can be inferred, if I figure it out one day I will definitely share it with you

[bisen2]

Also the idea is everything is code even typos and gibberish is appealing too

Personally, I would fundamentally disagree with this within a general purpose language. I think that this is a really interesting concept and not something I can think of any language that implements, but not something that I would want to see included in F# specifically. Most F# users (I imagine) aim to write robust and maintainable code, which this feature would get in the way of. That being said, I would love to see an esoteric language pop up centered around this concept to explore the potential use cases of this.