www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Uniform Function Call Syntax?

reply user001 <youdontneedthis dont.com> writes:
Was just wondering why UFCS only works in one direction, that is 
why functions can be used as if it were part of a struct/class 
but not the other way around.

struct Vec3
{
     float x;
     float y;
     float z;

     float dot(Vec3 o)
     {
         return x * o.x + y * o.y + z * o.z;
     }
}

int dot;
Vec3 a, b;

float value = dot(a, b); // would be same as a.dot(b)
                          // doesn't try to use local "int dot"


It may not add as much value but I think it'd be a bit better as 
now you no longer have a global function with a simple name 
"dot". For mathematical purposes it is a lot easier to understand 
"dot(a, b)" than "a.dot(b)", at least in my opinion. Just curious 
that's all.
Mar 03 2016
next sibling parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
 Was just wondering why UFCS only works in one direction, that 
 is why functions can be used as if it were part of a 
 struct/class but not the other way around.

 int dot;

 float value = dot(a, b); // would be same as a.dot(b)
                          // doesn't try to use local "int dot"
Immediately looking at only that part of the code, i have to ask 'how the hell are you calling the int???'. Of course i can tell from your source dot is also a function in the vector. Considering dot could now shadow the variables or function names, it would quickly QUICKLY become annoying. A hierarchy of how the call is used plus the documentation of what it's obviously doing is a much better approach. Not to mention we've been using . and -> and * so long for accessing/de-referencing members that are attached so long that changing it is probably not an option. MAYBE if you were starting a language from scratch, but in this case i would firmly say no, this is ugly and confusing.
Mar 03 2016
parent user001 <youdontneedthis dont.com> writes:
On Friday, 4 March 2016 at 02:09:25 UTC, Era Scarecrow wrote:
 On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
 Was just wondering why UFCS only works in one direction, that 
 is why functions can be used as if it were part of a 
 struct/class but not the other way around.

 int dot;

 float value = dot(a, b); // would be same as a.dot(b)
                          // doesn't try to use local "int dot"
Immediately looking at only that part of the code, i have to ask 'how the hell are you calling the int???'. Of course i can tell from your source dot is also a function in the vector. Considering dot could now shadow the variables or function names, it would quickly QUICKLY become annoying. A hierarchy of how the call is used plus the documentation of what it's obviously doing is a much better approach. Not to mention we've been using . and -> and * so long for accessing/de-referencing members that are attached so long that changing it is probably not an option.
You can say the same thing about how it is currently implemented. int[] arr = [ 0, 1, 2, 3 ]; static map(alias F)(int[]) { } writeln(arr.map!(a => a * 2)); // what does this mean array doesnt have a map function, does it use the local map function or the global one?
 MAYBE if you were starting a language from scratch, but in this 
 case i would firmly say no, this is ugly and confusing.
Well it could possibly be happening with C++17 so it's not that big of stretch to add it to an existing language, especially if that language already has it half implemented.
Mar 03 2016
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/3/2016 5:56 PM, user001 wrote:
 It may not add as much value but I think it'd be a bit better as now you no
 longer have a global function with a simple name "dot". For mathematical
 purposes it is a lot easier to understand "dot(a, b)" than "a.dot(b)", at least
 in my opinion. Just curious that's all.
If that's how you want to call dot, add the following: float dot(Vec3 a, Vec3 b) { return a.dot(b); }
Mar 05 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 4 March 2016 at 01:56:34 UTC, user001 wrote:
 "dot". For mathematical purposes it is a lot easier to 
 understand "dot(a, b)" than "a.dot(b)", at least in my opinion.
Why don't you just define it as "dot(a,b)" to begin with? I think it would be better idea to just add the ability to add unicode operators, and to avoid precedence issues one could just require them to use parentheses. That way you could define opCustom"•" and use it as: ( point1 • point2 ) An often stated golden rule in language design is that there should be one way to do something. When you break that rule it often is due to a language design deficiency. UFCS in both D and C++ are hacks. IMO that makes things more confusing, not more clear.
Mar 05 2016
next sibling parent reply Xinok <xinok live.com> writes:
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad 
wrote:
 I think it would be better idea to just add the ability to add 
 unicode operators, and to avoid precedence issues one could 
 just require them to use parentheses. That way you could define 
 opCustom"•" and use it as:

 ( point1 • point2 )
Please no. If I need to open up Character Map just to write code, something has gone horribly wrong.
Mar 06 2016
next sibling parent reply Patience <Patience.Is Virtue.Life> writes:
On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
 On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad 
 wrote:
 I think it would be better idea to just add the ability to add 
 unicode operators, and to avoid precedence issues one could 
 just require them to use parentheses. That way you could 
 define opCustom"•" and use it as:

 ( point1 • point2 )
Please no. If I need to open up Character Map just to write code, something has gone horribly wrong.
A proper code editor could handle this. Type something like ctrl + ? and it pops up all the implemented uni-code operators. Else we are stuck in the past until you decide to change...
Mar 06 2016
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Monday, 7 March 2016 at 06:02:46 UTC, Patience wrote:
 On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
 Please no. If I need to open up Character Map just to write 
 code, something has gone horribly wrong.
A proper code editor could handle this. Type something like ctrl + ? and it pops up all the implemented uni-code operators. Else we are stuck in the past until you decide to change...
I'm reminded. Weren't there standard 50-something keyboards, and then 101 keyboards? And you actually COULDN'T do programming on the 50-key keyboards because literally standard symbols were missing? Honestly it would be annoying to have to pull up character map, memorize ascii or unicode characters, or even require a helper program which isn't present on most tools. I have an excellent idea! I'll start programming using nothing but the greek alphabet, better yet unicode characters! //謎機能 int æ(File ß, int Ɣ, int Ʊ) { return Ɣ 乘 Ɣ 加 Ʊ 子 7; } Actually let's alias off the ints too because, we don't need those. //謎機能 數 æ(數 Ɣ, 數 Ʊ) { return Ɣ 乘 Ɣ 加 Ʊ 子 7; } i happy i cut & paste everywhere (instead of relying on standardized ascii characters that actually mean something to me... Okay maybe this went off track)
Mar 06 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 7 March 2016 at 06:48:10 UTC, Era Scarecrow wrote:
  I'm reminded. Weren't there standard 50-something keyboards, 
 and then 101 keyboards? And you actually COULDN'T do 
 programming on the 50-key keyboards because literally standard 
 symbols were missing?
No unicode. No keys. No mouse. No bitmap graphics. Just a hardwired terminal. Welcome to the 60s and 70s.
  I have an excellent idea! I'll start programming using nothing 
 but the greek alphabet, better yet unicode characters!
immutable π = 3.14; writeln( ∑(values) ); x = x + ∆; Oh, the horror!
Mar 06 2016
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
wrote:
 immutable π = 3.14;

 Oh, the horror!
With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi. As a reminder most of us are programmers, not scientists or mathematicians. Having specialized symbols won't give us any benefit. It's not like we're filling out a complex formula with college level math for a thesis.
Mar 06 2016
next sibling parent krzaq <dlangmailinglist krzaq.cc> writes:
On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
 On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
 wrote:
 immutable π = 3.14;

 Oh, the horror!
With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi. As a reminder most of us are programmers, not scientists or mathematicians. Having specialized symbols won't give us any benefit. It's not like we're filling out a complex formula with college level math for a thesis.
Didn't we have "pitching D to academia" thread recently? Honestly, any tool can be abused. Javascript, Swift and even partially Haskell allow unicode names and I'm sure we all saw that toy example that was full of emojis, but can you say it has been a problem in practice?
Mar 07 2016
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
 On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
 wrote:
 immutable π = 3.14;

 Oh, the horror!
With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi.
But you can already use "π" in D code? D is inconsistent in what parts of unicode you can use in names though. I don't think you can use "∂"...
  As a reminder most of us are programmers, not scientists or 
 mathematicians. Having specialized symbols won't give us any 
 benefit. It's not like we're filling out a complex formula with 
 college level math for a thesis.
Well, but you already have this possibility in D. Adding custom operators is just a small extension. And you don't have to use it if you don't want to. There is no standard english notation for the inner product either, "dot" refers to the sigil... But if you want both, you can have both. You can both have "innerProduct(v1,v2)" and "(v1 • v2)". In a commercial setting you want as high level of legibility as possible. D is doing slightly better than C++, but is far away from providing a good legible syntax. More time is spent reading code than writing it. In some cases people want to use their own language. D supports that. Math notation is no different than using a non-english language in that regard. Why shouldn't mathematicians be allowed to user the language they are familiar with if national languages are supported?
Mar 07 2016
parent reply Chris Wright <dhasenan gmail.com> writes:
On Mon, 07 Mar 2016 10:32:09 +0000, Ola Fosheim Grøstad wrote:
 D is inconsistent in what parts
 of unicode you can use in names though.
The basic idea is that you can use any letter or '_' as the first element of an identifier, and you can use any letter or number or '_' as a subsequent element of an identifier. That's simple and consistent, right? Except it's based on C99's fixed list of characters. So the actual rule is, you can use symbols from about 25 different writing systems that the designers of C99 thought prevalent enough to include, so long as they were in Unicode before 1999. C#, in contrast, uses Unicode categories. You can use the Cherokee alphabet in C# identifiers, and there are under 400,000 speakers of Cherokee. Making that work took far less effort for the C# standard authors than the choice of identifier characters for C99. I'm relatively certain that Walter went with C99's rules in large part because he had already implemented them, whereas he didn't have a readily available library with an appropriate license to give the Unicode category for a given codepoint.
 But you can already use "π" in D code?
U+03C0 (π) is from the Greek alphabet section of the Unicode inventory. It's for writing in the Greek language, which is currently spoken by about thirteen million people. It is primarily a letter, with incidental usage as a mathematical symbol. Therefore, based on the rule that you can always start an identifier with a letter, you can use π as an identifier.
 I don't think you can use "∂"...
The partial integral symbol is not a letter or digit under any circumstances. It is a mathematical symbol. Identifiers cannot contain mathematical symbols in D or C99 or even C#.
Mar 07 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote:
 The partial integral symbol is not a letter or digit under any 
 circumstances. It is a mathematical symbol. Identifiers cannot 
 contain mathematical symbols in D or C99 or even C#.
Well, but that argument is kinda bogus. Scientists have "invented" their own notation using whatever symbols (characters) they had access to since forever. It's not like they will stop just because language designers are reactionary. :-) There are lots of interesting letters from various languages that can be used, so prohibiting access to the proper symbols is kinda pointless. The end result is that people just pick inappropriate characters instead.
Mar 07 2016
next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Mon, 07 Mar 2016 18:45:34 +0000, Ola Fosheim Grøstad wrote:

 On Monday, 7 March 2016 at 18:35:44 UTC, Chris Wright wrote:
 The partial integral symbol is not a letter or digit under any
 circumstances. It is a mathematical symbol. Identifiers cannot contain
 mathematical symbols in D or C99 or even C#.
Well, but that argument is kinda bogus. Scientists have "invented" their own notation using whatever symbols (characters) they had access to since forever. It's not like they will stop just because language designers are reactionary. :-)
It's still not inconsistent to disallow math symbols. There's a simple rule that the C99 standards writers were attempting to approximate, and that simple rule excludes mathematical symbols. You dislike and disagree with that decision, which is a separate complaint. I'm sympathetic to the language designers here: I want to guide people toward using descriptive names, because that makes it easier to read code, which makes it easier to verify correctness. Math notation tends to be very compact and inscrutable, and I don't want to encourage users of my language to use inscrutable identifiers.
Mar 07 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 7 March 2016 at 18:57:03 UTC, Chris Wright wrote:
 It's still not inconsistent to disallow math symbols.
It is inconsistent if you accept that different communities have different notations/languages. Why you would you want to exclude the scientific community?
 here: I want to guide people toward using descriptive names, 
 because that makes it easier to read code, which makes it 
 easier to verify correctness.
Err, no, the contrary. What you get is an incomprehensible and overly verbose mess that hide problems and/or result in excessive overloading of the "*" symbol. Try some geometric computing problems, it gets messy quickly. People don't write descriptive names, they write short names, if you provide a very limited set of symbols. Like "dot".
Mar 07 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Mon, 07 Mar 2016 18:45:34 +0000, Ola Fosheim Grøstad wrote:
 There are lots of interesting letters from various languages that can be
 used, so prohibiting access to the proper symbols is kinda pointless.
 The end result is that people just pick inappropriate characters
 instead.
I don't think history bears that out. I've never seen this happen in Java, C#, or Python.
Mar 07 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 7 March 2016 at 19:09:47 UTC, Chris Wright wrote:
 I don't think history bears that out. I've never seen this 
 happen in Java, C#, or Python.
You haven't seen people do it in D?
Mar 08 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Tue, 08 Mar 2016 18:59:47 +0000, Ola Fosheim Grøstad wrote:

 On Monday, 7 March 2016 at 19:09:47 UTC, Chris Wright wrote:
 I don't think history bears that out. I've never seen this happen in
 Java, C#, or Python.
You haven't seen people do it in D?
No.
Mar 08 2016
prev sibling parent reply Lass Safin <lasssafin gmail.com> writes:
On Monday, 7 March 2016 at 07:58:53 UTC, Era Scarecrow wrote:
 On Monday, 7 March 2016 at 06:57:48 UTC, Ola Fosheim Grøstad 
 wrote:
 immutable π = 3.14;

 Oh, the horror!
With the assumption pi is declared elsewhere (say, in std.math), what i wonder is the number for pi vs 2 letters. Unicode 03C0h, so now i have to convert that to decimal, code 960. Alt+960 = └ That's not pi... Looking up the symbol by itself in the character map was annoying enough. No, this is not a good idea unless it's easily accessible, preferably with 2 or fewer keystrokes to symbolize pi. As a reminder most of us are programmers, not scientists or mathematicians. Having specialized symbols won't give us any benefit. It's not like we're filling out a complex formula with college level math for a thesis.
Have you ever heard of .XCompose? For linux: https://github.com/kragen/xcompose For windows: https://github.com/samhocevar/wincompose How it works: You choose a compose key, then use it to compose special characters with specific sequences. Examples: ComposeKey, *, p: π. ComposeKey, s, s: ß ComposeKey, ComposeKey, d, e, g, c (degree Celsius): ℃ It is not impossible to use unicode special characters on a daily base easily, with the use of this tool. No need to use the character map or anything. I think it would be very nice, if one had the option of using these special characters. E.g. → instead of >>, if you desire that; std.math defining π as π. Small gimmicks like these are things I find to be good for a language to have.
Mar 07 2016
parent Chris Wright <dhasenan gmail.com> writes:
On Mon, 07 Mar 2016 12:58:51 +0000, Lass Safin wrote:
 Have you ever heard of .XCompose?
 For linux: https://github.com/kragen/xcompose For windows:
 https://github.com/samhocevar/wincompose How it works:
 You choose a compose key, then use it to compose special characters with
 specific sequences.
Alternatively, you can create a custom keyboard layout for Linux relatively easily. The text format is relatively legible, but to simplify, you can use a utility such as https://github.com/simos/keyboardlayouteditor . For instance, I find myself using the characters ðþƹāē often for personal reasons, plus åøæ when I was learning Norwegian, so I created a keyboard layout to simplify that. Still doesn't make it a great idea, but if your code's audience is sufficiently constrained, you might find it makes some things more usable.
Mar 07 2016
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 7 March 2016 at 00:19:07 UTC, Xinok wrote:
 Please no. If I need to open up Character Map just to write 
 code, something has gone horribly wrong.
Modern languages support Unicode in names, so it is too late: import std.stdio; real Ø(real radius){ return 6.28*radius; } void main() { writeln(Ø(3)); }
Mar 06 2016
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07.03.2016 01:19, Xinok wrote:
 On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad wrote:
 I think it would be better idea to just add the ability to add unicode
 operators, and to avoid precedence issues one could just require them
 to use parentheses. That way you could define opCustom"•" and use it as:

 ( point1 • point2 )
Please no. If I need to open up Character Map just to write code, something has gone horribly wrong.
That "something" is your editor configuration. Seriously, this is a trivial problem.
Mar 07 2016
prev sibling parent reply Wyatt <wyatt.epp gmail.com> writes:
On Sunday, 6 March 2016 at 07:45:58 UTC, Ola Fosheim Grøstad 
wrote:
 I think it would be better idea to just add the ability to add 
 unicode operators, and to avoid precedence issues one could 
 just require them to use parentheses. That way you could define 
 opCustom"•" and use it as:
I've mentioned this before, but I think a constrained set of user-defined operators using annotations/affixes on the existing set is a better fit for D. It's a lesson well-learned from other languages (cf. OCaml; F#), and fits with D's generally practical bent. I mean, if you want to alias them to Lucky Charms or various hieroglyphs of birds disemboweling men later, I guess maybe that's could work? But I really don't want any language features predicated on the programmer having an APL keyboard. -Wyatt
Mar 07 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 7 March 2016 at 17:49:35 UTC, Wyatt wrote:
 I've mentioned this before, but I think a constrained set of 
 user-defined operators using annotations/affixes on the 
 existing set is a better fit for D.  It's a lesson well-learned 
 from other languages (cf. OCaml; F#), and fits with D's 
 generally practical bent.
Not sure what you mean by annotations/affixes and what lesson there is to be learned? What problems have other languages had with this?
 I mean, if you want to alias them to Lucky Charms or various 
 hieroglyphs of birds disemboweling men later, I guess maybe 
 that's could work? But I really don't want any language 
 features predicated on the programmer having an APL keyboard.
I don't see how mixfix notation makes this "problem" larger than the current prefix notation. Why is the current situation that allows "ø(x,y)" less problematic than the proposed "(x ø y)" ?
Mar 07 2016
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 07.03.2016 18:49, Wyatt wrote:
 But I really don't want any language features predicated on the
 programmer having an APL keyboard.
I can't think of any language feature that would be.
Mar 07 2016