<p>While in the shower thinking about my code, my mind went to C#'s type parameters, and I wondered what stops the type param from being placed in the middle of the function name like this:</p>
<pre><code>List&lt;T&gt; Numbers&lt;T&gt;() (normal)

List&lt;T&gt; LoadDataAs&lt;T&gt;From(string filename)
</code></pre>
<p>which would be called like this, which in my opinion is a much nicer and more expressive syntax:</p>
<pre><code>var Data = LoadDataAs&lt;float&gt;From(&quot;data.txt&quot;);
</code></pre>
<p>From there its easy to see how this could be expanded to standard parameters:</p>
<pre><code>Add(int number)To(object ComplexObject)

var complexObject = new ComplexObject();
Add(5)To(complexObject);
</code></pre>
<p>This would of course be syntactic sugar for standard function calls, and you could even permit placing arguments anywhere in a name, so long as they are in the correct order, meaning you wouldn't necesarily have to define functions using a special syntax like the above. As far as I can tell, it would be a simple transformation to move the arguments to the standard form, <code>AddTo(5, ComplexObject)</code> and then call.</p>
<p>Is this a viable syntax? I imagine it would cause havoc attempting autocomplete in a IDE, but are there any massive cons I'm missing?</p>

<syntax><functions>
Could function parameters be placed inside names?
CC BY-SA 4.0
2023-07-20T01:17:11.203Z
one possible drawback depending on the syntax of your langauge - it would cause ambiguity if it's ever valid to write two functions next to each other without calling them and without anything between them (for instance, if a list doesn't have to use explicit separators or for some kind of generalised implicit multiplication). also, with the proposed syntax for standard parameters, it's not immediately obvious how to refer to the function as a value (if that's something that's possible)
Silver
CC BY-SA 4.0
2023-07-20T16:24:09.293Z
I've done `Add(5).to(complexObject)`, and our Java testing library has `assertThat(complexObject).isEqualTo(5);`, which are close emulations of this feature.
Mooing Duck
CC BY-SA 4.0
2023-07-20T17:03:45.577Z
I'm suspicious that the syntax as presented will have a big ambiguity problem. In Objective C (I'm not sure about Smalltalk), method calls are always in square brackets, not bare: `[foo convertTo: bar withAccessories: baz]`. This version of the syntax doesn't leave any ambiguity about what is a function call.
Glenn Willen
CC BY-SA 4.0
2023-07-20T23:41:10.977Z
This idea is *Fan<Fu##ing>Tastic()*.  It also seems very SmallTalk-esque.
Mike Samuel
CC BY-SA 4.0
2023-07-21T15:24:03.767Z
Robotframework does something like this.
bob
<p>This is effectively <a href="https://en.wikipedia.org/wiki/Currying" rel="noreferrer">Currying</a> the function but with a name for each subfunction which can allow you to differentiate overloads.</p>
<p>That's kinda how objective C and swift do their calls. Though that is more <code>[object functionName:param1 paramName2:param2]</code></p>
<p>But you can easily convert that to a regular parenthesis syntax and drop the requirement for the first object.</p>
<p>If you use dot syntax <code>Add(5).To(complexObject);</code> then existing auto-completion will work fine assuming that Add returns a special type that has a To member function.</p>

CC BY-SA 4.0
2023-07-19T08:58:25.357Z
2023-07-19T08:58:25.357Z
ratchet freak
<p>Other answers are already great, so I'll juts drop a link to ObjectiveC example - a language widely used in Apple ecosystem until it recently gets replaced with Swift and other newer designs.</p>
<p>Check for example <a href="https://en.wikipedia.org/wiki/Objective-C#Interfaces_and_implementations" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Objective-C#Interfaces_and_implementations</a></p>
<pre><code>@interface classname : superclassname {
  // instance variables
}
+ classMethod1;
+ (return_type)classMethod2;
+ (return_type)classMethod3:(param1_type)param1_varName;

- (return_type)instanceMethod1With1Parameter:(param1_type)param1_varName;
- (return_type)instanceMethod2With2Parameters:(param1_type)param1_varName
                              param2_callName:(param2_type)param2_varName;
@end
</code></pre>
<p>The method3 and method2with2params show exactly that construct you asked about. It looks a bit clunky at first (if you are used to i.e. typical C/C++/C#/Java/etc notation), but after a tiny bit of getting used to (and with good naming scheme!!), it reads quite naturally..</p>
<p>Note that the ReturnType and ParamTypes are NOT part of the function name (partially that's why they are in parenthesis).</p>
<p>So:</p>
<pre><code>+ (return_type)classMethod3:(param1_type)param1_varName;
</code></pre>
<p>is a function named <code>classMethod3 param1_varName</code><br />
for example <code>sortBy NAME</code> (classmethod=sortBy; param1=NAME)</p>
<p>and</p>
<pre><code>- (return_type)instanceMethod2With2Parameters:(param1_type)param1_varName
                              param2_callName:(param2_type)param2_varName;
</code></pre>
<p>is a function named <code>instanceMethod2With2Parameters param1_varName param2_callName param2_varName</code><br />
for example: <code>sortBy NAME and AGE</code> (instancemethod=sortBy; param1=NAME; param2callname=and; param2=AGE)</p>
<p>Note that in the latter example, when function has 2 parameters or more, you can use these additional <code>callnames</code> like <code>by</code> - these do not affect the parameters at all. These are just interleaved additional parts of the function name, and they exist only for better readability of the function names. With them, you don't have to name parameters in &quot;weird&quot; way like &quot;byName&quot; or &quot;fromClient&quot;. The &quot;by&quot; and &quot;from&quot; are injected as extra parts, and parameters have natural identifiers: name, client.</p>

CC BY-SA 4.0
2023-07-20T19:39:05.093Z
2023-07-20T19:45:30.943Z
2023-07-20T19:45:30.943Z
quetzalcoatl
CC BY-SA 4.0
2023-07-21T02:18:45.823Z
There's already two other answers that mention Objective-C. Swift has also been around for nine years now, and I've seen Objective-C fairly infrequently in comparison to Swift (especially since the advent of SwiftUI).
Bbrk24
<p>These are <em>mixfix</em> or <em>multi-part</em> function names. They are most well known from Smalltalk, <a href="https://doi.org/10.1145/512760.512762" rel="noreferrer">introduced in Smalltalk-76</a>:</p>
<pre class="lang-none prettyprint-override"><code>aBoolean ifTrue: [ ... ] ifFalse: [ ... ]
4 between: 3 and: 5
</code></pre>
<p>but they can be included in any language, including with your syntax. My PhD work was with <a href="https://doi.org/10.1145/2445196.2445240" rel="noreferrer">a language</a> called <a href="http://gracelang.org/documents/grace-spec-0.7.0.html#method-names" rel="noreferrer">Grace</a> that had almost exactly that, in fact. It even used that form to define its control structures: <code>if (condition) then { ... } else { ... }</code> was a call to a three-part method name <code>if-then-else</code>. Each part of the name is followed by an argument list (and perhaps a type argument list), and a following identifier is parsed as beginning another part of the name. Your examples would all be valid and working method calls in a version of that language.</p>
<p>As well as Smalltalk and its derivatives, this sort of construction exists in Agda, Objective-C, Enso, Lean, and a number of other languages. Typically, the entire name is used as a method or function selector, including all of the parts in some canonicalised form. Sometimes only the first part is identifying, and the remainder are only used to label parameters. Both approaches are feasible and have representation, either as sugar for a more standard function call (e.g. in Agda, <code>if_then_else_</code> with three arguments) or specifically supported as multi-part message sends.</p>
<hr />
<p>There's no reason for IDE autocompletion to be any more trouble than usual. You will be able to have multiple candidate completions for any given prefix, but that situation exists anyway: whenever a function name is partially-typed, or in a language with overloading.  That's not a new issue, and is addressed in existing systems.</p>
<p>For the case where arguments can appear literally <em>anywhere</em> in the name, the completion would presumably be the remainder of the name, which may not be where the next argument would naturally be inserted. Adopting a structured multi-part approach like existing languages do is probably a better choice when this sort of tooling is desirable (and perhaps other times, too).</p>
<p>While this isn't an extremely common syntax, it's one that standard grammars are easily capable of expressing. Any tooling will be able to parse this construction, and only the normalisation of the components into a canonical identifier is an additional step to more typical syntax—and name-mangling isn't so rare, anyway.</p>
<hr />
<p>You can imagine still-more-flexible paths: with multiple parts to the name, it's plausible to allow declaring methods that identify calls by a pattern describing optional or repeated components, which we did in <a href="https://michael.homer.nz/Publications/DLS2015/LanguagesGeneralising-Homer2015.pdf" rel="noreferrer">this DLS'15 paper</a>. You could step back even further than that too and allow still-freer identifier grammars. There's no real obstacle to the limited form in the question except user unfamiliarity: all the parsing, compiling, and run-time issues are fairly trivial.</p>

CC BY-SA 4.0
2023-07-19T09:00:00.103Z
2023-07-19T09:33:38.983Z
2023-07-19T09:33:38.983Z
Michael Homer
CC BY-SA 4.0
2023-07-19T11:11:17.853Z
Does Objective-C not count as a derivative of Smalltalk?
Bbrk24
CC BY-SA 4.0
2023-07-19T18:44:31.113Z
@Bbrk24 I left it off the list originally and then decided somebody would complain it was unfair to lump it in as a true derivative. So… yes, but it’s hybrid enough to call out, I think.
Michael Homer
CC BY-SA 4.0
2023-07-19T18:55:42.167Z
@Bbrk24 Just tell me what /doesn't/ claim to be a derivative of Smalltalk these days. But its keyword syntax does have a lot going for it: unlike the rest of its left-to-right evaluation order which is- let's face it- only marginally better than APL's strict right-to-left evaluation.
Mark Morgan Lloyd
CC BY-SA 4.0
2023-07-19T19:33:59.577Z
@MarkMorganLloyd Objective-C is a lot closer to Smalltalk than any other C-family language I've seen. If nothing else I don't know of any other language that adopts their method call syntax, even if the class/metaclass situation is more common now. Also, everything claiming to be Smalltalk was a lot less true in 1982 when the OOPC was created.
Bbrk24
CC BY-SA 4.0
2023-07-20T22:29:47.443Z
See also [_Parsing Distfix Operators_](https://dl.acm.org/doi/abs/10.1145/5657.5659) (Peyton Jones, 1986).
davidbak
<p>A while ago, I built a language that did this: <a href="https://github.com/Telastyn/Tangent" rel="noreferrer">https://github.com/Telastyn/Tangent</a></p>
<pre><code>say (words : string) to (username : string) =&gt; void {
  print &quot;Dear:&quot;;
  print username;
  print &quot;&quot;;
  print words;
}

entrypoint =&gt; void {
  say &quot;Hello&quot; to &quot;World&quot;;
}
</code></pre>
<blockquote>
<p>are there any massive cons I'm missing?</p>
</blockquote>
<p>Many of the big cons in Tangent are related to the dynamic dispatch, but the flexible syntax didn't help. <code>object.function(params)</code> syntax is very easy to parse left to right. More importantly, it's very <em>efficient</em> to parse left to right. As soon as you run into parameters first or multiple identifiers or expression nesting, things get dangerous.</p>
<p>Is <code>Add(5)To(complexObject)</code> one function call or two function calls (or three function calls because <code>Add(5)</code> returns a partially applied delegate)? You'll be tempted to parse more of the expression to disambiguate things which will effectively change your grammar from context free to a context sensitive one - including all of the computational complexity that entails.</p>

CC BY-SA 4.0
2023-07-19T18:40:17.247Z
2023-07-19T18:40:17.247Z
Telastyn
# Could function parameters be placed inside names?
Posted by: username_0 on 2023-07-19
While in the shower thinking about my code, my mind went to C#'s type parameters, and I wondered what stops the type param from being placed in the middle of the function name like this:
List Numbers() (normal)

List LoadDataAsFrom(string filename)

which would be called like this, which in my opinion is a much nicer and more expressive syntax:
var Data = LoadDataAsFrom("data.txt");

From there its easy to see how this could be expanded to standard parameters:
Add(int number)To(object ComplexObject)

var complexObject = new ComplexObject();
Add(5)To(complexObject);

This would of course be syntactic sugar for standard function calls, and you could even permit placing arguments anywhere in a name, so long as they are in the correct order, meaning you wouldn't necesarily have to define functions using a special syntax like the above. As far as I can tell, it would be a simple transformation to move the arguments to the standard form, AddTo(5, ComplexObject) and then call.
Is this a viable syntax? I imagine it would cause havoc attempting autocomplete in a IDE, but are there any massive cons I'm missing?
**Tags:** syntax functions
> **Comments:**
> **username_1**: one possible drawback depending on the syntax of your langauge - it would cause ambiguity if it's ever valid to write two functions next to each other without calling them and without anything between them (for instance, if a list doesn't have to use explicit separators or for some kind of generalised implicit multiplication). also, with the proposed syntax for standard parameters, it's not immediately obvious how to refer to the function as a value (if that's something that's possible)  
> **username_2**: I've done `Add(5).to(complexObject)`, and our Java testing library has `assertThat(complexObject).isEqualTo(5);`, which are close emulations of this feature.  
> **username_3**: I'm suspicious that the syntax as presented will have a big ambiguity problem. In Objective C (I'm not sure about Smalltalk), method calls are always in square brackets, not bare: `[foo convertTo: bar withAccessories: baz]`. This version of the syntax doesn't leave any ambiguity about what is a function call.  
> **username_4**: This idea is *Fan<Fu##ing>Tastic()*.  It also seems very SmallTalk-esque.  
> **username_5**: Robotframework does something like this.  
---
## 4 answers
### Answer by username_9 on 2023-07-19. Score: 30 | Accepted answer
These are mixfix or multi-part function names. They are most well known from Smalltalk, introduced in Smalltalk-76:
aBoolean ifTrue: [ ... ] ifFalse: [ ... ]
4 between: 3 and: 5

but they can be included in any language, including with your syntax. My PhD work was with a language called Grace that had almost exactly that, in fact. It even used that form to define its control structures: if (condition) then { ... } else { ... } was a call to a three-part method name if-then-else. Each part of the name is followed by an argument list (and perhaps a type argument list), and a following identifier is parsed as beginning another part of the name. Your examples would all be valid and working method calls in a version of that language.
As well as Smalltalk and its derivatives, this sort of construction exists in Agda, Objective-C, Enso, Lean, and a number of other languages. Typically, the entire name is used as a method or function selector, including all of the parts in some canonicalised form. Sometimes only the first part is identifying, and the remainder are only used to label parameters. Both approaches are feasible and have representation, either as sugar for a more standard function call (e.g. in Agda, if_then_else_ with three arguments) or specifically supported as multi-part message sends.

There's no reason for IDE autocompletion to be any more trouble than usual. You will be able to have multiple candidate completions for any given prefix, but that situation exists anyway: whenever a function name is partially-typed, or in a language with overloading.  That's not a new issue, and is addressed in existing systems.
For the case where arguments can appear literally anywhere in the name, the completion would presumably be the remainder of the name, which may not be where the next argument would naturally be inserted. Adopting a structured multi-part approach like existing languages do is probably a better choice when this sort of tooling is desirable (and perhaps other times, too).
While this isn't an extremely common syntax, it's one that standard grammars are easily capable of expressing. Any tooling will be able to parse this construction, and only the normalisation of the components into a canonical identifier is an additional step to more typical syntax—and name-mangling isn't so rare, anyway.

You can imagine still-more-flexible paths: with multiple parts to the name, it's plausible to allow declaring methods that identify calls by a pattern describing optional or repeated components, which we did in this DLS'15 paper. You could step back even further than that too and allow still-freer identifier grammars. There's no real obstacle to the limited form in the question except user unfamiliarity: all the parsing, compiling, and run-time issues are fairly trivial.
> **Comments:**
> **username_8** (2023-07-19): Does Objective-C not count as a derivative of Smalltalk?  
> **username_9** (2023-07-19): @Bbrk24 I left it off the list originally and then decided somebody would complain it was unfair to lump it in as a true derivative. So… yes, but it’s hybrid enough to call out, I think.  
> **username_10** (2023-07-19): @Bbrk24 Just tell me what /doesn't/ claim to be a derivative of Smalltalk these days. But its keyword syntax does have a lot going for it: unlike the rest of its left-to-right evaluation order which is- let's face it- only marginally better than APL's strict right-to-left evaluation.  
> **username_8** (2023-07-19): @MarkMorganLloyd Objective-C is a lot closer to Smalltalk than any other C-family language I've seen. If nothing else I don't know of any other language that adopts their method call syntax, even if the class/metaclass situation is more common now. Also, everything claiming to be Smalltalk was a lot less true in 1982 when the OOPC was created.  
> **username_11** (2023-07-20): See also [_Parsing Distfix Operators_](https://dl.acm.org/doi/abs/10.1145/5657.5659) (Peyton Jones, 1986).  
---
### Answer by username_12 on 2023-07-19. Score: 9
A while ago, I built a language that did this: https://github.com/Telastyn/Tangent
say (words : string) to (username : string) => void {
  print "Dear:";
  print username;
  print "";
  print words;
}

entrypoint => void {
  say "Hello" to "World";
}


are there any massive cons I'm missing?

Many of the big cons in Tangent are related to the dynamic dispatch, but the flexible syntax didn't help. object.function(params) syntax is very easy to parse left to right. More importantly, it's very efficient to parse left to right. As soon as you run into parameters first or multiple identifiers or expression nesting, things get dangerous.
Is Add(5)To(complexObject) one function call or two function calls (or three function calls because Add(5) returns a partially applied delegate)? You'll be tempted to parse more of the expression to disambiguate things which will effectively change your grammar from context free to a context sensitive one - including all of the computational complexity that entails.
---
### Answer by username_6 on 2023-07-19. Score: 8
This is effectively [Currying](https://en.wikipedia.org/wiki/Currying) the function but with a name for each subfunction which can allow you to differentiate overloads.

That's kinda how objective C and swift do their calls. Though that is more `[object functionName:param1 paramName2:param2]`

But you can easily convert that to a regular parenthesis syntax and drop the requirement for the first object.

If you use dot syntax `Add(5).To(complexObject);` then existing auto-completion will work fine assuming that Add returns a special type that has a To member function.
---
### Answer by username_7 on 2023-07-20. Score: 2
Other answers are already great, so I'll juts drop a link to ObjectiveC example - a language widely used in Apple ecosystem until it recently gets replaced with Swift and other newer designs.
Check for example https://en.wikipedia.org/wiki/Objective-C#Interfaces_and_implementations
@interface classname : superclassname {
  // instance variables
}
+ classMethod1;
+ (return_type)classMethod2;
+ (return_type)classMethod3:(param1_type)param1_varName;

- (return_type)instanceMethod1With1Parameter:(param1_type)param1_varName;
- (return_type)instanceMethod2With2Parameters:(param1_type)param1_varName
                              param2_callName:(param2_type)param2_varName;
@end

The method3 and method2with2params show exactly that construct you asked about. It looks a bit clunky at first (if you are used to i.e. typical C/C++/C#/Java/etc notation), but after a tiny bit of getting used to (and with good naming scheme!!), it reads quite naturally..
Note that the ReturnType and ParamTypes are NOT part of the function name (partially that's why they are in parenthesis).
So:
+ (return_type)classMethod3:(param1_type)param1_varName;

is a function named classMethod3 param1_varName
for example sortBy NAME (classmethod=sortBy; param1=NAME)
and
- (return_type)instanceMethod2With2Parameters:(param1_type)param1_varName
                              param2_callName:(param2_type)param2_varName;

is a function named instanceMethod2With2Parameters param1_varName param2_callName param2_varName
for example: sortBy NAME and AGE (instancemethod=sortBy; param1=NAME; param2callname=and; param2=AGE)
Note that in the latter example, when function has 2 parameters or more, you can use these additional callnames like by - these do not affect the parameters at all. These are just interleaved additional parts of the function name, and they exist only for better readability of the function names. With them, you don't have to name parameters in "weird" way like "byName" or "fromClient". The "by" and "from" are injected as extra parts, and parameters have natural identifiers: name, client.
> **Comments:**
> **username_8** (2023-07-21): There's already two other answers that mention Objective-C. Swift has also been around for nine years now, and I've seen Objective-C fairly infrequently in comparison to Swift (especially since the advent of SwiftUI).  
---
