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.




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
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 



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



 
 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
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 



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



 
 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 

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 

 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