![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||
|
![]() | This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
The term ¨Syntactic aspartame¨ has been thrown around lately whilst discussing pugs. Anyone care to enlarge the current article? elpincha 19:30, 27 February 2006 (UTC)
Suggest we merge 'Syntactic saccharin' and 'Syntactic Splenda' sections into one, and include this variant in the text. Twifkak 02:49, 10 December 2006 (UTC)
The last paragraph (Splenda) needs rewriting.
I removed this:
"A Mediawiki example would be the ability of signing one's comments in talk pages with --~~~~. The users could manually insert the Wiki code that this is short for, but the syntactic sugar makes it easier."
It's hard to argue that "~~~~" is sugar; it's more like a
macro. Especially for the default expansion, it is not simply the case that users could manually insert the "equivalent" code, because this requires them to know their IP address (at least for anonymous users) and the time at the Mediawiki servers in UTC. It's comparable to macros like __LINE__
in C, expanding to the current line number: you could conceivably go through the trouble of finding the expansion out yourself, but that doesn't make the construct syntactic sugar.
As an aside, how notable are the "syntactic foo" variants people have come up with? "Syntactic sugar" and "syntactic salt" are in common use, but the others look like obscure, one-off expressions to me. Not every clever variation people think of should make it into an encyclopedia. 194.151.6.70 22:20, 25 November 2006 (UTC)
As an aside, how notable are the "syntactic foo" variants people have come up with? "Syntactic sugar" and "syntactic salt" are in common use, but the others look like obscure, one-off expressions to me. Not every clever variation people think of should make it into an encyclopedia.
I agree with this. A DHH blog post is not a reasonable source for an encyclopedia. I've removed that one, others are welcome to put it back or remove others they know to be 'one off' terms. 24.52.132.106 22:45, 5 December 2006 (UTC)
I also agree. I have never heard of "Syntactic saccharin" and the definition provided does not seem to follow the same analogy as saccharin adds sweetness without adding (many) calories. In that sense it would follow that "Syntactic saccharin" provides the benefits of "Syntactic sugar" with less added syntax. The definition provided suggests that it instead provides no additional sweetness but still adds mass, making it more like an inert "Syntactic salt". But regardless of the definition we give, the term does not appear to be in wide circulation. 216.36.186.2 ( talk) 16:00, 7 January 2008 (UTC)
However many modern, "sugar-rich" languages (such as C#) cannot be desugared. Still, their features may be considered "sugar" because primitives exist in predecessor languages (such as C) to fully recreate them.
One would be lead to believe that if a predecessor language can fully recreate the features in a derivative, then this is in fact the definition of syntactic sugar. This needs to be cited, or the fact C is not a subset of C# needs to be explained. —Preceding unsigned comment added by 142.151.168.69 ( talk) 04:33, 8 February 2008 (UTC)
I believe that the basic definition the article starts with -- "Syntactic sugar is a term coined by Peter J. Landin for additions to the syntax of a computer language that do not affect its functionality but make it "sweeter" for humans to use." -- is incorrect. It implies that syntactic sugar is an "addition" to an existing programming language and that therefore syntactic sugar can be "translated back" into the language. That was not Landin's point at all. Most languages (certainly when he was writing) did not support anonymous functions (lambda expressions), for example. -- Macrakis ( talk) 00:27, 5 July 2008 (UTC)
The phrase "Alternative Terms" makes me think of synonyms. Maybe renaming it to "Related Terms" or "Similar Terms," or something? Txmy ( talk) 19:24, 7 December 2008 (UTC)
Sorry, I think that this article examples go to far in what they consider to be "syntactic sugar". IMO if ___exactly the same___ can be obtained with a slightly more complicated construct, then it's syntactic sugar. One example is Pascal's "with" keyword:
with something { a = 3; myfunction(x); }
is
something.a = 3; something.myfunction(x);
with some sugar.
But I don't think C-style for loop is not syntactic sugar.
for(A;B;C) body ;
might look the same as:
A; while(B) { body ; C ; }
but the for() variant adds some functionality. If you "continue" from inside the body, the code in "C" still gets evaluated. Replicating this behavior on the while() might require the use of flag variables, or duplicating the code for C.
Then it goes with replacing while() with goto's. I just think that this is going too far, and using the same arguments you can argue that the whole C language is syntactic sugar over assembler, then assembler is syntactic sugar for machine code (hey, I can buy that one), and then machine code is just syntactic sugar over placing the 1 and 0 directly into the memory. 84.77.96.100 ( talk) 16:34, 17 July 2009 (UTC)
The existing example states that the address of the memory cell containing a[i][j] is *(*(a + i) + j), rather than *(a + i * columns-per-row + j). The former would perhaps be more appropriate for (a[i])[j]. Any objections to my replacing this strange construct with the one for the more common double dimensional array? Traumerei ( talk) 04:20, 17 February 2010 (UTC)
I agree with Traumerei.*(a+i) is itself syntactic sugar for
shall i go ahead and and make the corrections he suggested? R6im3t ( talk) 08:06, 9 May 2010 (UTC)
For the primitive array type, a[i][j] is not equivalent to *(*(a + i) + j), since the array is the single indirection as described by Traumerei, while the double indirection will treat the element at (a + i) as a pointer.Consider the following code snippet 'a[2][2] = { { 0, 0 }, {0 , 0} }; *(*(a + 1) + 0) = 1; // should be a[1][0] = 1': if executed as describe will dereference 0 (NULL pointer) since *(a + 1) = 0. 2-dimensional arrays in C/C++ are not arrays of arrays: a primitive array type is just a pointer in C/C++ regardless of dimension. The syntax is a convenient way to specify some ranking of elements from the base address. A lot of C++ texts seem to have this kind of error since objects that mimic the array syntax may actually use double indirection logic and syntax such as 'a[2][2]; int * ptr = a[1];' are allowed (which means that 'ptr = (a + 1)', which is still correct since 'a' is a pointer). I think the article could benefit from explicitly pointing out this type of obfuscation: things look like they are doing one thing but are really doing something else due to a perceived need to make the syntax uniform (appealing/sweet). It as an example showing the perils of syntactic sugar or at least bad abstraction in my opinion (it would be easier to think that each [] is an indirection but for primitive C/C++ arrays it isn't). 173.206.27.201 ( talk) 13:50, 22 May 2010 (UTC)
int a[2][2]; cout << &a << endl; cout << a << endl; cout << *a << endl;
Dereferencing pointer to array does no indirection, it simply changes type.
Drundia (
talk)
16:38, 23 April 2013 (UTC)There is now absolutely no concrete examples of syntactic sugar on this page apart from those two rather vague sentence in the beginning (and the case of the for loop in C is far from cut and dried, as other commentators remarked). The section on Derivative terms (which I never heard anywhere before whereas syntactic sugar is often used) is actually far bigger than the examples. I note that examples were removed in the past. Is it fine to add some properly referenced and illustrated examples once again ? For instance, Haskell is a language that has several examples of syntactic sugar that are clearly labeled as such and translated back to primitives in the Haskell Report. The string literal example was badly presented but is very much true in at least two senses : interpolation, and case like Haskell where strings are simply list of characters with a special syntax. Jedai ( talk) 19:57, 20 January 2012 (UTC)
I'm not an expert so please correct me if I'm wrong; I think Perl's use of => as an exact synonym for a comma (most often used in declarations of hash literals) is an uncontentious example. AFAICT, it exists purely to make code easier to read and has no other semantic effects. 80.176.190.231 ( talk) 18:30, 18 February 2012 (UTC)
I'm not fully happy with the "Augmented Assignment" example. In C# [1], for example, the form "a += b" is not equivalent to "a = a + b", even though it usually produces the same results. Here's an example, in C#, of its not producing the same result:
int TimesRead; //This is set to 1 when b is fetched int b { get { int a = TimesRead; TimesRead = 1; return a; } } // end: b
public void WikiSugarDemo() { int[] a;
a = new[] { 3, 10 }; TimesRead = 0; a[b] = a[b] + 2; Console.WriteLine( "Using a[b] = a[b] + 2:\t" + "a[0]=" + a[0] + "; a[1]=" + a[1] );
a = new[] { 3, 10 }; TimesRead = 0; a[b] += 2; Console.WriteLine( "Using a[b] += 2:\t" + "a[0]=" + a[0] + "; a[1]=" + a[1] );
//Generated output: // //Using a[b] = a[b] + 2: a[0]=12; a[1]=10 //Using a[b] += 2: a[0]=5; a[1]=10
} // end: WikiSugarDemo()
I think that a suitable example of "syntactic sugar" might be the C# "var" keyword (called an "implicitly typed local variable declaration"), which may sometimes be used to substitute for an explicit type specification. The sugary part of "var" is that it avoids repeating a lengthy type name; e.g., the statement
System.Collections.Generic.List<string> d = new System.Collections.Generic.List<string>();
may be shortened to
var d = new System.Collections.Generic.List<string>();
(Use of "var" is sometimes necessary, as when the expression is of an anonymous type.)
-- PoisonCat1 ( talk) 08:41, 17 March 2014 (UTC)
References
Does operator overloading count as syntactic sugar? It feels like it to me, but I don't believe I'm experienced enough to fully trust my opinion on this.
class Integer { int val;
public: Integer(int i) : val(i) {} operator int() { return val; }
Integer& operator+=(const Integer& other) { val += other.val; return *this; } };
Integer operator+(const Integer& l, const Integer& r) { Integer ret = l; ret += r; return ret; }
In this case, operator+() serves as syntactic sugar for creating a new Integer equivalent to the sum of two other Integers.
Integer i = 5, j = 10;
Integer k = i + j;
/* Equivalent to... * * Integer k = operator+(i, j); * * Which is itself sugar for... * * Integer k = i; k += j; * * Which is ITSELF sugar for accessing and modifying k's field * "val" directly. */
Not 100% sure if this counts.
Alternatively, the C++11 type deduction rules can be seen as syntactic sugar (albeit extremely valuable sugar), which can be used similarly to var in the above C# example.
// Old: std::vector<int>::iterator it = vec.begin();
// C++11: auto it = vec.begin();
This is both sugar, and extremely useful in contexts where the actual type isn't necessarily known to the programmer; it uses template type deduction rules, so the type can be determined for you by the compiler in most cases.
-- 173.237.102.207 ( talk) 04:43, 8 January 2017 (UTC)
Are the inner classes in Java and from there the lambdas in Java 8 a good extended example of syntactic sugar?
When you write:
button.addActionListener((e)->System.out.println("Hello world"));
this is the short form of:
button.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { System.out.prinln("Hello world"); } });
and even this still gets some major changes at compile time because inner classes are like normal classes but with a special link to the outer class. Piegames ( talk) 13:11, 7 June 2017 (UTC)
In C++, C# and D, auto-type declarations can be used to declare a variable whose type is not known at coding time when doing generic programming. In this respect, it is arguably a feature that adds power to the languages in question, thus not syntactic sugar.
That said, you could argue that auto x = expr;
is syntactic sugar for typeof(expr) x = expr;
in D, or decltype(expr) x = expr;
in C++11. But I'm not sure that the same can be said about C# or Java. —
Smjg (
talk)
23:17, 30 August 2022 (UTC)
I think the given example for syntactic sugar in OOP languages isn't very good, as it's underselling what's going on within OOP under the hood.
myObject.myMethod(parameter1, parameter2, parameter3)
is syntactic sugar for calling a global function as myMethod(myObject, parameter1, parameter2, parameter3)
. The reference to the object is passed as a hidden argument, usually accessible from within the method as this
.This is true in the specific case of final methods, or in more recent languages like Kotlin, static extension methods. However, this does not apply to typical object methods. For example, in Java, myList.get(index)
cannot be replaced with some global List.get(myList, index)
. At runtime, when get
is called, the runtime does a dynamic dispatch to the get
method specific to the class of myList
, uniquely tailored to that particular class and able to access its private fields.
There is no way to recapture the full functionality and expressive power of this dynamic dispatch with the rest of Java's feature, so it cannot be considered syntactic sugar.
I think a better example for OOP would be the for-each loop, which on arrays is syntactic sugar for a for-loop for each index in the array, and on Iterable
s is syntactic sugar for a while-loop using its Iterator
. This still demonstrates a unique advantage of OOP with the Iterable
interface, but is true syntactic sugar.
Derektom14 (
talk)
07:22, 17 June 2023 (UTC)
The cobol
move a to b
goes beyond syntactic sugar, in that the 'in' can be removed without any other change, and the line remains valid and does the same thing (whereas doing C strings without quotes requires some work). Back in the day, these were sometimes called noise words. There were various programs that could take COBOL source and add (or remove) all the noise words, which was handy when your manager used "amount of code written" as a metric. 203.13.3.89 ( talk) 04:28, 11 April 2024 (UTC)
???
is not a syntactic sugar, and the Stack Overflow article linked in the citation proves the point that it indeed is not. Instead, it is a utility method that happens to be composed of non-alphanumeric characters. Since this is not based on a syntactic replacement, but instead based on a name-lookup (and hence it can be shadowed by another definition with the same name), I believe this does not qualify as a syntactic sugar even though it does seem like one at first sight.
Example code:
object Test { def ??? : Nothing = throw new RuntimeException("new ??? implementation here!") def main(args: Array[String]): Unit = ??? }
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||
|
![]() | This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later. |
The term ¨Syntactic aspartame¨ has been thrown around lately whilst discussing pugs. Anyone care to enlarge the current article? elpincha 19:30, 27 February 2006 (UTC)
Suggest we merge 'Syntactic saccharin' and 'Syntactic Splenda' sections into one, and include this variant in the text. Twifkak 02:49, 10 December 2006 (UTC)
The last paragraph (Splenda) needs rewriting.
I removed this:
"A Mediawiki example would be the ability of signing one's comments in talk pages with --~~~~. The users could manually insert the Wiki code that this is short for, but the syntactic sugar makes it easier."
It's hard to argue that "~~~~" is sugar; it's more like a
macro. Especially for the default expansion, it is not simply the case that users could manually insert the "equivalent" code, because this requires them to know their IP address (at least for anonymous users) and the time at the Mediawiki servers in UTC. It's comparable to macros like __LINE__
in C, expanding to the current line number: you could conceivably go through the trouble of finding the expansion out yourself, but that doesn't make the construct syntactic sugar.
As an aside, how notable are the "syntactic foo" variants people have come up with? "Syntactic sugar" and "syntactic salt" are in common use, but the others look like obscure, one-off expressions to me. Not every clever variation people think of should make it into an encyclopedia. 194.151.6.70 22:20, 25 November 2006 (UTC)
As an aside, how notable are the "syntactic foo" variants people have come up with? "Syntactic sugar" and "syntactic salt" are in common use, but the others look like obscure, one-off expressions to me. Not every clever variation people think of should make it into an encyclopedia.
I agree with this. A DHH blog post is not a reasonable source for an encyclopedia. I've removed that one, others are welcome to put it back or remove others they know to be 'one off' terms. 24.52.132.106 22:45, 5 December 2006 (UTC)
I also agree. I have never heard of "Syntactic saccharin" and the definition provided does not seem to follow the same analogy as saccharin adds sweetness without adding (many) calories. In that sense it would follow that "Syntactic saccharin" provides the benefits of "Syntactic sugar" with less added syntax. The definition provided suggests that it instead provides no additional sweetness but still adds mass, making it more like an inert "Syntactic salt". But regardless of the definition we give, the term does not appear to be in wide circulation. 216.36.186.2 ( talk) 16:00, 7 January 2008 (UTC)
However many modern, "sugar-rich" languages (such as C#) cannot be desugared. Still, their features may be considered "sugar" because primitives exist in predecessor languages (such as C) to fully recreate them.
One would be lead to believe that if a predecessor language can fully recreate the features in a derivative, then this is in fact the definition of syntactic sugar. This needs to be cited, or the fact C is not a subset of C# needs to be explained. —Preceding unsigned comment added by 142.151.168.69 ( talk) 04:33, 8 February 2008 (UTC)
I believe that the basic definition the article starts with -- "Syntactic sugar is a term coined by Peter J. Landin for additions to the syntax of a computer language that do not affect its functionality but make it "sweeter" for humans to use." -- is incorrect. It implies that syntactic sugar is an "addition" to an existing programming language and that therefore syntactic sugar can be "translated back" into the language. That was not Landin's point at all. Most languages (certainly when he was writing) did not support anonymous functions (lambda expressions), for example. -- Macrakis ( talk) 00:27, 5 July 2008 (UTC)
The phrase "Alternative Terms" makes me think of synonyms. Maybe renaming it to "Related Terms" or "Similar Terms," or something? Txmy ( talk) 19:24, 7 December 2008 (UTC)
Sorry, I think that this article examples go to far in what they consider to be "syntactic sugar". IMO if ___exactly the same___ can be obtained with a slightly more complicated construct, then it's syntactic sugar. One example is Pascal's "with" keyword:
with something { a = 3; myfunction(x); }
is
something.a = 3; something.myfunction(x);
with some sugar.
But I don't think C-style for loop is not syntactic sugar.
for(A;B;C) body ;
might look the same as:
A; while(B) { body ; C ; }
but the for() variant adds some functionality. If you "continue" from inside the body, the code in "C" still gets evaluated. Replicating this behavior on the while() might require the use of flag variables, or duplicating the code for C.
Then it goes with replacing while() with goto's. I just think that this is going too far, and using the same arguments you can argue that the whole C language is syntactic sugar over assembler, then assembler is syntactic sugar for machine code (hey, I can buy that one), and then machine code is just syntactic sugar over placing the 1 and 0 directly into the memory. 84.77.96.100 ( talk) 16:34, 17 July 2009 (UTC)
The existing example states that the address of the memory cell containing a[i][j] is *(*(a + i) + j), rather than *(a + i * columns-per-row + j). The former would perhaps be more appropriate for (a[i])[j]. Any objections to my replacing this strange construct with the one for the more common double dimensional array? Traumerei ( talk) 04:20, 17 February 2010 (UTC)
I agree with Traumerei.*(a+i) is itself syntactic sugar for
shall i go ahead and and make the corrections he suggested? R6im3t ( talk) 08:06, 9 May 2010 (UTC)
For the primitive array type, a[i][j] is not equivalent to *(*(a + i) + j), since the array is the single indirection as described by Traumerei, while the double indirection will treat the element at (a + i) as a pointer.Consider the following code snippet 'a[2][2] = { { 0, 0 }, {0 , 0} }; *(*(a + 1) + 0) = 1; // should be a[1][0] = 1': if executed as describe will dereference 0 (NULL pointer) since *(a + 1) = 0. 2-dimensional arrays in C/C++ are not arrays of arrays: a primitive array type is just a pointer in C/C++ regardless of dimension. The syntax is a convenient way to specify some ranking of elements from the base address. A lot of C++ texts seem to have this kind of error since objects that mimic the array syntax may actually use double indirection logic and syntax such as 'a[2][2]; int * ptr = a[1];' are allowed (which means that 'ptr = (a + 1)', which is still correct since 'a' is a pointer). I think the article could benefit from explicitly pointing out this type of obfuscation: things look like they are doing one thing but are really doing something else due to a perceived need to make the syntax uniform (appealing/sweet). It as an example showing the perils of syntactic sugar or at least bad abstraction in my opinion (it would be easier to think that each [] is an indirection but for primitive C/C++ arrays it isn't). 173.206.27.201 ( talk) 13:50, 22 May 2010 (UTC)
int a[2][2]; cout << &a << endl; cout << a << endl; cout << *a << endl;
Dereferencing pointer to array does no indirection, it simply changes type.
Drundia (
talk)
16:38, 23 April 2013 (UTC)There is now absolutely no concrete examples of syntactic sugar on this page apart from those two rather vague sentence in the beginning (and the case of the for loop in C is far from cut and dried, as other commentators remarked). The section on Derivative terms (which I never heard anywhere before whereas syntactic sugar is often used) is actually far bigger than the examples. I note that examples were removed in the past. Is it fine to add some properly referenced and illustrated examples once again ? For instance, Haskell is a language that has several examples of syntactic sugar that are clearly labeled as such and translated back to primitives in the Haskell Report. The string literal example was badly presented but is very much true in at least two senses : interpolation, and case like Haskell where strings are simply list of characters with a special syntax. Jedai ( talk) 19:57, 20 January 2012 (UTC)
I'm not an expert so please correct me if I'm wrong; I think Perl's use of => as an exact synonym for a comma (most often used in declarations of hash literals) is an uncontentious example. AFAICT, it exists purely to make code easier to read and has no other semantic effects. 80.176.190.231 ( talk) 18:30, 18 February 2012 (UTC)
I'm not fully happy with the "Augmented Assignment" example. In C# [1], for example, the form "a += b" is not equivalent to "a = a + b", even though it usually produces the same results. Here's an example, in C#, of its not producing the same result:
int TimesRead; //This is set to 1 when b is fetched int b { get { int a = TimesRead; TimesRead = 1; return a; } } // end: b
public void WikiSugarDemo() { int[] a;
a = new[] { 3, 10 }; TimesRead = 0; a[b] = a[b] + 2; Console.WriteLine( "Using a[b] = a[b] + 2:\t" + "a[0]=" + a[0] + "; a[1]=" + a[1] );
a = new[] { 3, 10 }; TimesRead = 0; a[b] += 2; Console.WriteLine( "Using a[b] += 2:\t" + "a[0]=" + a[0] + "; a[1]=" + a[1] );
//Generated output: // //Using a[b] = a[b] + 2: a[0]=12; a[1]=10 //Using a[b] += 2: a[0]=5; a[1]=10
} // end: WikiSugarDemo()
I think that a suitable example of "syntactic sugar" might be the C# "var" keyword (called an "implicitly typed local variable declaration"), which may sometimes be used to substitute for an explicit type specification. The sugary part of "var" is that it avoids repeating a lengthy type name; e.g., the statement
System.Collections.Generic.List<string> d = new System.Collections.Generic.List<string>();
may be shortened to
var d = new System.Collections.Generic.List<string>();
(Use of "var" is sometimes necessary, as when the expression is of an anonymous type.)
-- PoisonCat1 ( talk) 08:41, 17 March 2014 (UTC)
References
Does operator overloading count as syntactic sugar? It feels like it to me, but I don't believe I'm experienced enough to fully trust my opinion on this.
class Integer { int val;
public: Integer(int i) : val(i) {} operator int() { return val; }
Integer& operator+=(const Integer& other) { val += other.val; return *this; } };
Integer operator+(const Integer& l, const Integer& r) { Integer ret = l; ret += r; return ret; }
In this case, operator+() serves as syntactic sugar for creating a new Integer equivalent to the sum of two other Integers.
Integer i = 5, j = 10;
Integer k = i + j;
/* Equivalent to... * * Integer k = operator+(i, j); * * Which is itself sugar for... * * Integer k = i; k += j; * * Which is ITSELF sugar for accessing and modifying k's field * "val" directly. */
Not 100% sure if this counts.
Alternatively, the C++11 type deduction rules can be seen as syntactic sugar (albeit extremely valuable sugar), which can be used similarly to var in the above C# example.
// Old: std::vector<int>::iterator it = vec.begin();
// C++11: auto it = vec.begin();
This is both sugar, and extremely useful in contexts where the actual type isn't necessarily known to the programmer; it uses template type deduction rules, so the type can be determined for you by the compiler in most cases.
-- 173.237.102.207 ( talk) 04:43, 8 January 2017 (UTC)
Are the inner classes in Java and from there the lambdas in Java 8 a good extended example of syntactic sugar?
When you write:
button.addActionListener((e)->System.out.println("Hello world"));
this is the short form of:
button.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { System.out.prinln("Hello world"); } });
and even this still gets some major changes at compile time because inner classes are like normal classes but with a special link to the outer class. Piegames ( talk) 13:11, 7 June 2017 (UTC)
In C++, C# and D, auto-type declarations can be used to declare a variable whose type is not known at coding time when doing generic programming. In this respect, it is arguably a feature that adds power to the languages in question, thus not syntactic sugar.
That said, you could argue that auto x = expr;
is syntactic sugar for typeof(expr) x = expr;
in D, or decltype(expr) x = expr;
in C++11. But I'm not sure that the same can be said about C# or Java. —
Smjg (
talk)
23:17, 30 August 2022 (UTC)
I think the given example for syntactic sugar in OOP languages isn't very good, as it's underselling what's going on within OOP under the hood.
myObject.myMethod(parameter1, parameter2, parameter3)
is syntactic sugar for calling a global function as myMethod(myObject, parameter1, parameter2, parameter3)
. The reference to the object is passed as a hidden argument, usually accessible from within the method as this
.This is true in the specific case of final methods, or in more recent languages like Kotlin, static extension methods. However, this does not apply to typical object methods. For example, in Java, myList.get(index)
cannot be replaced with some global List.get(myList, index)
. At runtime, when get
is called, the runtime does a dynamic dispatch to the get
method specific to the class of myList
, uniquely tailored to that particular class and able to access its private fields.
There is no way to recapture the full functionality and expressive power of this dynamic dispatch with the rest of Java's feature, so it cannot be considered syntactic sugar.
I think a better example for OOP would be the for-each loop, which on arrays is syntactic sugar for a for-loop for each index in the array, and on Iterable
s is syntactic sugar for a while-loop using its Iterator
. This still demonstrates a unique advantage of OOP with the Iterable
interface, but is true syntactic sugar.
Derektom14 (
talk)
07:22, 17 June 2023 (UTC)
The cobol
move a to b
goes beyond syntactic sugar, in that the 'in' can be removed without any other change, and the line remains valid and does the same thing (whereas doing C strings without quotes requires some work). Back in the day, these were sometimes called noise words. There were various programs that could take COBOL source and add (or remove) all the noise words, which was handy when your manager used "amount of code written" as a metric. 203.13.3.89 ( talk) 04:28, 11 April 2024 (UTC)
???
is not a syntactic sugar, and the Stack Overflow article linked in the citation proves the point that it indeed is not. Instead, it is a utility method that happens to be composed of non-alphanumeric characters. Since this is not based on a syntactic replacement, but instead based on a name-lookup (and hence it can be shadowed by another definition with the same name), I believe this does not qualify as a syntactic sugar even though it does seem like one at first sight.
Example code:
object Test { def ??? : Nothing = throw new RuntimeException("new ??? implementation here!") def main(args: Array[String]): Unit = ??? }