<p>What would it take to design a language that permitted construct such as below?</p>
<pre><code>int int = 10;
</code></pre>
<p>Such a language would need to be able to infer contextually whether a type name or an expression is expected. Are there any constructs in a C++ or Java style language that would be equally valid whether a type name or an expression is used in any particular place, making them truly ambiguous if the identifier was both defined as an expression and a type? How can they be worked around syntactically?</p>

<types><identifiers><variables><namespaces>
Types and variables in a different namespace
<h1>Function call or type cast?</h1>
<p>One example of an ambiguous statement in a C-style language that supports type names and object names overlapping is if there is a function or function pointer called <code>x</code> and a type called <code>x</code>.</p>
<p>The expression <code>(x)(10)</code> would be ambiguous because there is no way of knowing just by looking if I am calling the <code>x</code> object with <code>10</code> as an argument, or if I am casting <code>10</code> to type <code>x</code>.</p>
<p>One way to disambiguate is to use an extra set of parenthesis around the <code>x</code> like <code>((x))(10)</code>. This would unambiguously refer to the function call because as there is no expression after <code>(x)</code> in this case so there is no cast.</p>
<p>Types cannot be 'parenthesized' by themselves by putting parenthesis around an ambiguous name so we are forcing the compiler to treat the name as an expression.</p>
<p>As such, in ambiguous cases, the type name can be the 'default.' And to opt into the expression version, we can place parenthesis around the type.</p>

CC BY-SA 4.0
2023-11-18T23:38:51.697Z
2023-11-18T23:38:51.697Z
CPlus
CC BY-SA 4.0
2023-11-19T00:14:28.423Z
Then again, functions are usually called _without_ the starting parentheses, so it would _usually_ be safe for a compiler/interpreter/whatever to default to the latter case.
Someone
<p>A number of existing languages do allow this and there is no particular issue with it. Java permits it for reference types, for example, as do C# and Scala:</p>
<pre class="lang-java prettyprint-override"><code>Foo Bar = new Foo();
Bar Foo = new Bar();
</code></pre>
<p>This code is accepted, and works without issue and generally without ambiguity.</p>
<p>There <em>is</em> one ambiguous construct this creates in the Java model: ordinarily, <code>Foo.meth()</code> calls the static method <code>meth</code> on the <code>Foo</code> class, but now it will attempt to dispatch on the variable instead and either fail or find an unrelated method from type <code>Bar</code>.  A different language could distinguish instance and static method access syntactically and not face this issue, or simply not have them, or not overload the name of the type with the name of the class.</p>
<p>Many languages have no meaningful dynamic existence of types (or associated entities) at all, and these would generally not have even the opportunity for a run-time issue to arise. These are not forced to disambiguate at all.</p>
<p>Strictly speaking, this is also doable in a number of functional languages with algebraic data types and first-class functions. For example, in the Haskell code</p>
<pre class="lang-haskell prettyprint-override"><code>data Foo = Foo Int
x = Foo
</code></pre>
<p>the second <code>Foo</code> is in the value namespace, holding a function from <code>Int</code> to <code>Foo</code>. Both type and function do remain available in their contexts as usual. However, this variable can't have any other value than that, so it may not meet the spirit of the question.</p>
<p>There's then no particular semantic problem with allowing this, and certainly nothing that rules it out entirely.</p>
<hr />
<p>As well as these semantic issues, there can be syntactic ones: C famously has context-dependent lexing due to typedefs already, and generally requires feeding names of declared types into the lexer so that it can disambiguate <code>(A)*B</code> as a cast or multiplication. Given <code>int int = 10</code>, <strong><code>(int)*x</code> would be terminally ambiguous</strong>.</p>
<p>It would be possible to constrain the syntax rules so this can't be written, in this case for example by requiring that the pointer dereference be written <code>(*x)</code>, but it is a deeper change. Similar issues might arise in other languages that would otherwise benefit from a clear distinction between type and variable names.</p>
<hr />
<p>From a language-design perspective, <strong>having types (or classes, constructors, ...) as first-class values in a shared namespace is quite fundamental</strong>, and a language that did not allow it would be very different. This is a choice that the language is making, probably deliberately. For example, first-class values for these may be used for dependency injection, higher-order programming, or pattern matching, and core to the ergonomics of the language.</p>
<hr />
<p>All in all, allowing this is within the range of choices available to the language designer. There are tradeoffs involved in that, and it may be incompatible with other, more important features, but certainly not <em>ruled out</em> entirely if different choices are made.</p>

CC BY-SA 4.0
2023-05-24T02:18:27.733Z
2023-05-24T02:18:27.733Z
Michael Homer
<p>This is already possible in some popular programming languages: for example, Java and Typescript both allow this.</p>
<pre class="lang-java prettyprint-override"><code>class Foo {
    static Foo Foo = new Foo();
}
</code></pre>
<pre class="lang-typescript prettyprint-override"><code>type Foo = {foo: string}
const Foo: Foo = {foo: 'foo'};
</code></pre>
<p>So long as the type name is an identifier and not a keyword, it's sufficient to not have first-class types, so that the type name isn't also an expression which refers to the type object as a value. (Of course, if the name is a keyword then it can't also be an identifier for a variable name.)</p>
<p>Or even if you do have first-class types, this might still allowed when the variable is declared in a different scope, so that it shadows the binding of the name to the type object. This would probably be very limited though, since the expression <code>new Foo()</code> would probably then resolve to the local name rather than the type.</p>

CC BY-SA 4.0
2023-05-23T23:51:18.520Z
2023-11-18T23:31:39.723Z
2023-11-18T23:31:39.723Z
kaya3
CC BY-SA 4.0
2023-05-23T23:56:45.327Z
Even in some languages with first-class types, they have some extra syntax to make it unambiguous, like `Foo.self` in Swift or `typeof(Foo)` in C#.
Bbrk24
CC BY-SA 4.0
2023-05-24T00:07:19.000Z
It is still a problem to access static methods or fields from the type in Java without being first-class.
Michael Homer
CC BY-SA 4.0
2023-05-24T00:15:38.893Z
@MichaelHomer True. `((Foo) null).bar()` would be available as a workaround for that where `bar` is a static method. (And it won't throw a null pointer exception, because Java gonna Java.)
kaya3
CC BY-SA 4.0
2023-05-24T00:19:59.193Z
Oh, that's horrific.
Michael Homer
# Types and variables in a different namespace
Posted by: username_0 on 2023-05-23
What would it take to design a language that permitted construct such as below?
int int = 10;

Such a language would need to be able to infer contextually whether a type name or an expression is expected. Are there any constructs in a C++ or Java style language that would be equally valid whether a type name or an expression is used in any particular place, making them truly ambiguous if the identifier was both defined as an expression and a type? How can they be worked around syntactically?
**Tags:** types identifiers variables namespaces
---
## 3 answers
### Answer by username_2 on 2023-05-24. Score: 6 | Accepted answer
A number of existing languages do allow this and there is no particular issue with it. Java permits it for reference types, for example, as do C# and Scala:
Foo Bar = new Foo();
Bar Foo = new Bar();

This code is accepted, and works without issue and generally without ambiguity.
There is one ambiguous construct this creates in the Java model: ordinarily, Foo.meth() calls the static method meth on the Foo class, but now it will attempt to dispatch on the variable instead and either fail or find an unrelated method from type Bar.  A different language could distinguish instance and static method access syntactically and not face this issue, or simply not have them, or not overload the name of the type with the name of the class.
Many languages have no meaningful dynamic existence of types (or associated entities) at all, and these would generally not have even the opportunity for a run-time issue to arise. These are not forced to disambiguate at all.
Strictly speaking, this is also doable in a number of functional languages with algebraic data types and first-class functions. For example, in the Haskell code
data Foo = Foo Int
x = Foo

the second Foo is in the value namespace, holding a function from Int to Foo. Both type and function do remain available in their contexts as usual. However, this variable can't have any other value than that, so it may not meet the spirit of the question.
There's then no particular semantic problem with allowing this, and certainly nothing that rules it out entirely.

As well as these semantic issues, there can be syntactic ones: C famously has context-dependent lexing due to typedefs already, and generally requires feeding names of declared types into the lexer so that it can disambiguate (A)*B as a cast or multiplication. Given int int = 10, (int)*x would be terminally ambiguous.
It would be possible to constrain the syntax rules so this can't be written, in this case for example by requiring that the pointer dereference be written (*x), but it is a deeper change. Similar issues might arise in other languages that would otherwise benefit from a clear distinction between type and variable names.

From a language-design perspective, having types (or classes, constructors, ...) as first-class values in a shared namespace is quite fundamental, and a language that did not allow it would be very different. This is a choice that the language is making, probably deliberately. For example, first-class values for these may be used for dependency injection, higher-order programming, or pattern matching, and core to the ergonomics of the language.

All in all, allowing this is within the range of choices available to the language designer. There are tradeoffs involved in that, and it may be incompatible with other, more important features, but certainly not ruled out entirely if different choices are made.
---
### Answer by username_3 on 2023-05-23. Score: 4
This is already possible in some popular programming languages: for example, Java and Typescript both allow this.
class Foo {
    static Foo Foo = new Foo();
}

type Foo = {foo: string}
const Foo: Foo = {foo: 'foo'};

So long as the type name is an identifier and not a keyword, it's sufficient to not have first-class types, so that the type name isn't also an expression which refers to the type object as a value. (Of course, if the name is a keyword then it can't also be an identifier for a variable name.)
Or even if you do have first-class types, this might still allowed when the variable is declared in a different scope, so that it shadows the binding of the name to the type object. This would probably be very limited though, since the expression new Foo() would probably then resolve to the local name rather than the type.
> **Comments:**
> **username_4** (2023-05-23): Even in some languages with first-class types, they have some extra syntax to make it unambiguous, like `Foo.self` in Swift or `typeof(Foo)` in C#.  
> **username_2** (2023-05-24): It is still a problem to access static methods or fields from the type in Java without being first-class.  
> **username_3** (2023-05-24): @MichaelHomer True. `((Foo) null).bar()` would be available as a workaround for that where `bar` is a static method. (And it won't throw a null pointer exception, because Java gonna Java.)  
> **username_2** (2023-05-24): Oh, that's horrific.  
---
### Answer by username_0 on 2023-11-18. Score: 1
# Function call or type cast?

One example of an ambiguous statement in a C-style language that supports type names and object names overlapping is if there is a function or function pointer called `x` and a type called `x`.

The expression `(x)(10)` would be ambiguous because there is no way of knowing just by looking if I am calling the `x` object with `10` as an argument, or if I am casting `10` to type `x`.

One way to disambiguate is to use an extra set of parenthesis around the `x` like `((x))(10)`. This would unambiguously refer to the function call because as there is no expression after `(x)` in this case so there is no cast.

Types cannot be 'parenthesized' by themselves by putting parenthesis around an ambiguous name so we are forcing the compiler to treat the name as an expression.

As such, in ambiguous cases, the type name can be the 'default.' And to opt into the expression version, we can place parenthesis around the type.
> **Comments:**
> **username_1** (2023-11-19): Then again, functions are usually called _without_ the starting parentheses, so it would _usually_ be safe for a compiler/interpreter/whatever to default to the latter case.  
---
