Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58253 > unrolled thread

What is "complexifying" C?

Back to article view | Back to comp.lang.c

Contents

  What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-16 22:55 +0100
    Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-16 22:55 +0000
      Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 16:41 -0700
        Re: What is "complexifying"  C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 00:05 +0000
        Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 01:12 +0000
        Re: What is "complexifying"  C? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:58 -0700
      Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 07:16 +0100
        Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 13:50 +0000
          Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 14:59 +0100
            Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:22 +0100
              Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-17 16:16 +0100
            Re: What is "complexifying"  C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-17 14:39 +0000
            Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 15:23 +0000
          Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:40 -0700
          Re: What is "complexifying"  C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-18 22:49 +0000
            Re: What is "complexifying"  C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 13:55 +0000
              Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 15:37 +0000
                Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-19 23:06 +0100
                  Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 22:38 +0000
                    Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 19:43 +1300
                      Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 07:49 +0100
                      Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 02:29 -0500
                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 21:37 +1300
                          Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 03:40 -0500
                            Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-20 10:18 +0100
                              Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-21 00:19 -0500
                          Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 03:15 -0700
                            Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 13:51 +1300
                              Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 15:21 +1300
                              Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 00:57 -0700
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 22:28 +1300
                                  Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-22 02:59 -0700
                                  Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 11:16 -0700
                                    Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 07:25 +1300
                                      Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 12:06 -0700
                                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:01 +1300
                                          Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 03:09 -0700
                                        Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-23 01:42 -0700
                                    Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 19:32 +0100
                                      Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-22 17:34 -0500
                                        Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 20:07 -0400
                                          Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 00:00 -0500
                                            Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:04 +1300
                                            Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-23 23:22 -0400
                                    Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 14:54 -0400
                              Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-23 00:35 +0100
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:06 +1300
                              Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:25 +1300
                                Re: What is "complexifying" C? Martin Shobe <martin.shobe@yahoo.com> - 2015-03-22 23:33 -0500
                                Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:01 +1300
                                  Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 09:41 -0400
                                    Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 10:23 -0400
                                      Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-24 07:10 +1300
                                        Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 14:57 -0400
                                          Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 09:36 +0100
                                            Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 08:42 +0000
                                              Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 11:23 +0100
                                                Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 10:52 +0000
                              Re: What is "complexifying" C? raltbos@xs4all.nl (Richard Bos) - 2015-03-29 16:58 +0000
                            Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 02:38 +0100
                            Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 09:11 -0400
                        Re: What is "complexifying" C? Les Cargill <lcargill99@comcast.com> - 2015-03-20 06:30 -0500
                      Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-20 10:31 +0000
                      Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-20 13:49 +0000
                        Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 09:23 -0700
                        Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-21 08:28 +1300
                  Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 01:04 -0700
      Re: What is "complexifying"  C? Keith Thompson <kst-u@mib.org> - 2015-03-17 08:05 -0700
        Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 16:08 +0100
          Re: What is "complexifying"  C? Keith Thompson <kst-u@mib.org> - 2015-03-17 11:09 -0700
            Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 21:37 +0100
              Re: What is "complexifying"  C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 00:40 -0500
        Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 15:34 +0000
      Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 15:06 +0000
    Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-17 00:05 +0100
    Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 23:20 +0000
    Re: What is "complexifying"  C? Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:42 +1300
    Re: What is "complexifying"  C? Mark Storkamp <mstorkamp@yahoo.com> - 2015-03-17 08:59 -0500
      Re: What is "complexifying"  C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:18 +0100
      Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-17 14:41 +0000
        Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:47 -0700
          Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-19 00:26 +0000
            Re: What is "complexifying"  C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-19 03:23 -0700
              Re: What is "complexifying"  C? Bartc <bc@freeuk.com> - 2015-03-19 11:19 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#58253 — What is "complexifying" C?

There are now following number types in C:

1) char (signed and unsigned)
2) short (signed/unsigned)
3) int (signed/unsigned)
4) long (signed/unsigned)
5) long long (signed/unsigned)

That makes for 10 integer types
11) float
12) double
13) long double
14) float _Complex
15) double _Complex
16) long double _Complex

That makes for 16 different types of numbers. In advanced 
standardization process we have

Decimal floats
Fixed point numbers

We have many different types of floating extensions (with more 
precision) or integer extensions (bignums) and a long list of possible 
other types of numbers for different applications, like numbers defined 
by an interval for easing error analysis, etc.

Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it 
proposes a SINGLE mechanism that would allow users to implement their 
own number types without adding the enormous complexity of integrating 
all those numbers into the compiler itself.

The reasoning that operator overloading makes C more complex is wrong, 
actually the opposite is the case. Adding specific types of numbers into 
the language itself makes the implementations even *more* complex, and 
forces decisions into the committee that should be actually left to the 
users!

[toc] | [next] | [standalone]

#58254

On 16/03/2015 21:55, jacob navia wrote:
> There are now following number types in C:
>
> 1) char (signed and unsigned)
> 2) short (signed/unsigned)
> 3) int (signed/unsigned)
> 4) long (signed/unsigned)
> 5) long long (signed/unsigned)
>
> That makes for 10 integer types
> 11) float
> 12) double
> 13) long double
> 14) float _Complex
> 15) double _Complex
> 16) long double _Complex
>
> That makes for 16 different types of numbers

That's one way of looking at it (and you forgot about _Bool). Another 
way is:

(1) signed integers
(2) unsigned integers
(3) floating point

With a range of widths for each (typically four widths for integers, and 
two for floating point). You make the width an attribute rather a 
completely distinct type. Yes, I've left out _Complex, but I doubt many 
people care.

> We have many different types of floating extensions (with more
> precision) or integer extensions (bignums) and a long list of possible
> other types of numbers for different applications, like numbers defined
> by an interval for easing error analysis, etc.

It's debatable whether such application-specific types should be the 
concern of the language, especially a low-level one such as C.

> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
> proposes a SINGLE mechanism that would allow users to implement their
> own number types without adding the enormous complexity of integrating
> all those numbers into the compiler itself.

OK, so now users have to create their own DIY compiler! All the standard 
types are already integrated so that work is already done.

I just don't think that you can introduce something such as operator 
overloading without a lot of extra complexity, and importing half of 
what's in C++.

Even if you did it, at some point someone will demand inheritance 
(because they create a new numeric usertype U that is based on an 
existing numeric usertype T). Then you'll have to drag in the rest of C++.

> The reasoning that operator overloading makes C more complex is wrong,
> actually the opposite is the case. Adding specific types of numbers into
> the language itself makes the implementations even *more* complex, and
> forces decisions into the committee that should be actually left to the
> users!

I can see the problem you're trying to solve, but perhaps there's a 
better way than adding general operator overloads.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58260

On Monday, March 16, 2015 at 10:55:24 PM UTC, Bart wrote:
>
> That's one way of looking at it (and you forgot about _Bool). Another 
> way is:
> 
> (1) signed integers
> (2) unsigned integers
> (3) floating point
>
A better way of thinking of it is 
(1) integer data (observations constrained to be whole numbers)
(2) real data (observations not constrained to be whole numbers)
(3) indexing and counting - integers to look up arrays or occasionally
other structures of data.
(4) string data - data that is human readable.
(5) bitstream data - data is an ordered sequence of bits.

Whilst this list isn't exhaustive, for example you can have imaginary,
rational, boolean, time, glyph, function, graph and other values
in a program, it's a reasonable list for data types in a language
like C. Everything can of course be built from integers or bitstreams.

The question is how to strike the right balance between types
that make sense in program space, and efficiency. 
> 
> I can see the problem you're trying to solve, but perhaps there's a 
> better way than adding general operator overloads.
> 
overloading operators to create new scalar types isn't something
the user space programmer should really be doing. It's appropriate
maybe for someone producing an implementation of a language for a
specific platform.

[toc] | [prev] | [next] | [standalone]

#58261

On 16/03/15 23:41, Malcolm McLean wrote:

<snip>

> overloading operators to create new scalar types isn't something
> the user space programmer should really be doing.

I'd *love* to see operator overloading in C (and no, that doesn't mean I 
think it's a good idea), and for precisely the reason upon which you 
appear to frown.

I would love to be able to write:

Date EasterSunday = GetEaster(2015);
PalmSunday = EasterSunday - 7;

or, and this is <cough> a fabulous example:

AliceSendsToBob = prime ? AliceSecret : ModNum;

(which would calculate Prime to the power AliceSecret, modulo ModNum - a 
clear abuse of operator overloading, but there isn't a powmod operator.)

RSA, Diffie-Hellman, and date manipulation are obvious candidates for 
taking advantage of operator overloading. Why do you think it's a bad 
idea? (NB I am not advocating that C should be changed to incorporate 
operator overloading.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#58263

On 16/03/2015 23:41, Malcolm McLean wrote:
> On Monday, March 16, 2015 at 10:55:24 PM UTC, Bart wrote:
>>
>> That's one way of looking at it (and you forgot about _Bool). Another
>> way is:
>>
>> (1) signed integers
>> (2) unsigned integers
>> (3) floating point
>>
> A better way of thinking of it is
> (1) integer data (observations constrained to be whole numbers)
> (2) real data (observations not constrained to be whole numbers)
> (3) indexing and counting - integers to look up arrays or occasionally
> other structures of data.
> (4) string data - data that is human readable.
> (5) bitstream data - data is an ordered sequence of bits.
>
> Whilst this list isn't exhaustive, for example you can have imaginary,
> rational, boolean, time, glyph, function, graph and other values
> in a program, it's a reasonable list for data types in a language
> like C. Everything can of course be built from integers or bitstreams.

That's probably a bit ambitious for C (although I know Jacob likes to 
promote it as a general purpose language suitable for all applications). 
It's almost too ambitious for Ada...

> The question is how to strike the right balance between types
> that make sense in program space, and efficiency.

To deal fully with types, you are going to end up with a bad imitation 
of Ada. (And with overloading, with a poor man's version of C++)

I think it's important to impose some boundaries to how far you extend a 
language, before it crosses over into a different class of language.

So to my list of three numeric types, I might add bits, as a fourth kind 
(rather than be narrower versions of (1) and (2), because they are a 
little special.)

>>
>> I can see the problem you're trying to solve, but perhaps there's a
>> better way than adding general operator overloads.
>>
> overloading operators to create new scalar types isn't something
> the user space programmer should really be doing. It's appropriate
> maybe for someone producing an implementation of a language for a
> specific platform.

Exactly. That's the main reason I don't like C++. The mechanisms for 
enabling the user to do that start to dominate the language. It then 
also becomes too easy to create your own private language that no-one 
else can understand.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#58967

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Monday, March 16, 2015 at 10:55:24 PM UTC, Bart wrote:
>
>> That's one way of looking at it (and you forgot about _Bool).  Another 
>> way is:
>>
>> (1) signed integers
>> (2) unsigned integers
>> (3) floating point
>
> A better way of thinking of it is [snip]

s/better/Malcolm/

[toc] | [prev] | [next] | [standalone]

#58268

Le 16/03/2015 23:55, Bartc a écrit :
<jacob wrote>
>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>> proposes a SINGLE mechanism that would allow users to implement their
>> own number types without adding the enormous complexity of integrating
>> all those numbers into the compiler itself.
>
> OK, so now users have to create their own DIY compiler! All the standard
> types are already integrated so that work is already done.

Yes but it is done following the desires of the language implementor.

Does he/she prefers accuracy to speed?

The user has NO possibility to change the way those operations are done.

And ALL other types of numbers that users need can't be programmed in C.

[toc] | [prev] | [next] | [standalone]

#58287

On 2015-03-17, jacob navia <jacob@spamsink.net> wrote:
> Le 16/03/2015 23:55, Bartc a écrit :
><jacob wrote>
>>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>>> proposes a SINGLE mechanism that would allow users to implement their
>>> own number types without adding the enormous complexity of integrating
>>> all those numbers into the compiler itself.
>>
>> OK, so now users have to create their own DIY compiler! All the standard
>> types are already integrated so that work is already done.
>
> Yes but it is done following the desires of the language implementor.
>
> Does he/she prefers accuracy to speed?
>
> The user has NO possibility to change the way those operations are done.
>
> And ALL other types of numbers that users need can't be programmed in C.

Could you give an example? I think of operator overloading as syntactic
sugar. Is there something that can be done with it that can't be done
otherwise?

-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58290

Le 17/03/2015 14:50, Greg Martin a écrit :
> On 2015-03-17, jacob navia <jacob@spamsink.net> wrote:
>> Le 16/03/2015 23:55, Bartc a écrit :
>> <jacob wrote>
>>>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>>>> proposes a SINGLE mechanism that would allow users to implement their
>>>> own number types without adding the enormous complexity of integrating
>>>> all those numbers into the compiler itself.
>>>
>>> OK, so now users have to create their own DIY compiler! All the standard
>>> types are already integrated so that work is already done.
>>
>> Yes but it is done following the desires of the language implementor.
>>
>> Does he/she prefers accuracy to speed?
>>
>> The user has NO possibility to change the way those operations are done.
>>
>> And ALL other types of numbers that users need can't be programmed in C.
>
> Could you give an example? I think of operator overloading as syntactic
> sugar. Is there something that can be done with it that can't be done
> otherwise?
>

1) If you have the "/" (divide) operation in the language itself, you 
can't change it. That means that the decisions of the compiler writer 
are unchangeable. If the compiler writer prefers speed over accuracy you 
are bound to that decision. This is of no importance when doing a 
floating point division, but it is not the same for complex division, 
for instance.

2) Without operator overloading the expression

	c = (A+B)/(A-B) +A*B;
becomes
	c = add(divide(add(A,B),subtract(A,B)),multiply(A,B));

Yes, it is "syntactic sugar" but C is just "syntactic sugar" over raw 
assembly also.

[toc] | [prev] | [next] | [standalone]

#58296 — Re: What is "complexifying" C?

Le 17/03/2015 15:09, Stefan Ram a écrit :
> C++/already has/  the whole support framework such as
>    classes and user-defined literals.

C# also has that.

Fortran also has that.

But when I propose that C should have that,the C++ guys get anxious...

Why?

Because after years of efforts, after years of C++ hype people still 
prefer C.

:-)

[toc] | [prev] | [next] | [standalone]

#58312 — Re: What is "complexifying" C?

On 17/03/15 15:22, jacob navia wrote:
> Le 17/03/2015 15:09, Stefan Ram a écrit :
>> C++/already has/  the whole support framework such as
>>    classes and user-defined literals.
> 
> C# also has that.
> 
> Fortran also has that.
> 
> But when I propose that C should have that,the C++ guys get anxious...
> 

It is not C++ fans that have been against the proposals - it is C fans.
 (Though C++ fans are quick to point out when a given feature already
exists in C++.)  You seem to think that C++ fans are worried that if
your ideas make it into C, no one will use C++ any more!

> Why?
> 
> Because after years of efforts, after years of C++ hype people still
> prefer C.
> 

Back here on planet earth, C++ is a massively popular language.

Some people think C is better for some types of job - and they are
correct.  Some people think C++ is better for some types of job - and
they are also correct.  Some people prefer C or C++ when either language
is a reasonable choice - and it is a fine thing that they have that choice.

You prefer C with some unusual extensions, and you are in the lucky
position of being able to write the compiler yourself.  That's great.
But don't be surprised when other people prefer standard C or standard C++.

[toc] | [prev] | [next] | [standalone]

#58302

On 2015-03-17, jacob navia <jacob@spamsink.net> wrote:
> 2) Without operator overloading the expression
>
> 	c = (A+B)/(A-B) +A*B;
> becomes
> 	c = add(divide(add(A,B),subtract(A,B)),multiply(A,B));

I don't agree, because "add", "divide", etc could be overloaded.

What you're discussing above is infix versus prefix.

Infix is syntactic sugar over function calls.

Function calls can be completely static, resolved by name to a single
implementation.

Or they can be generic to the point of doing run-time dispatch
to multiple methods on the run-time types of the arguments.

I can transliterate the above into Lisp and then write methods
that make add and subtract work with any kinds of numbers or other
objects:

 (setf c (add (divide (add A B) (subtract A B)) (multiply A B)))

 (defmethod divide ((left my-number-class) (right integer))
  ...)

 (defmethod divide ((left integer) (right my-number-class))
  ...)

I.e. ihe infix notation isn't the feature which allows new numbers to be
implemented; what does that is the dispatch flexibility in the implied
functions.

In C++, note that, say, the + operator is understood to correspond to a
function notated as operator +(...). You write this function.

The "overloading" part comes from the possibility that this function
supports overloading: multiple implementations with different
type signatures. It does this in common with non-operator functions.

   // Regular named overloaded function
   mynumber add(const mynumber &left, int right)
   {
     // ...
   }

   // Operator wrapper for above
   mynumber &operator +(const mynumber &left, int right)
   {
     return add(left, right);
   }

[toc] | [prev] | [next] | [standalone]

#58314

On 2015-03-17, jacob navia <jacob@spamsink.net> wrote:
> Le 17/03/2015 14:50, Greg Martin a écrit :
>> On 2015-03-17, jacob navia <jacob@spamsink.net> wrote:
>>> Le 16/03/2015 23:55, Bartc a écrit :
>>> <jacob wrote>
>>>>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>>>>> proposes a SINGLE mechanism that would allow users to implement their
>>>>> own number types without adding the enormous complexity of integrating
>>>>> all those numbers into the compiler itself.
>>>>
>>>> OK, so now users have to create their own DIY compiler! All the standard
>>>> types are already integrated so that work is already done.
>>>
>>> Yes but it is done following the desires of the language implementor.
>>>
>>> Does he/she prefers accuracy to speed?
>>>
>>> The user has NO possibility to change the way those operations are done.
>>>
>>> And ALL other types of numbers that users need can't be programmed in C.
>>
>> Could you give an example? I think of operator overloading as syntactic
>> sugar. Is there something that can be done with it that can't be done
>> otherwise?
>>
>
> 1) If you have the "/" (divide) operation in the language itself, you 
> can't change it. That means that the decisions of the compiler writer 
> are unchangeable. If the compiler writer prefers speed over accuracy you 
> are bound to that decision. This is of no importance when doing a 
> floating point division, but it is not the same for complex division, 
> for instance.
>
> 2) Without operator overloading the expression
>
> 	c = (A+B)/(A-B) +A*B;
> becomes
> 	c = add(divide(add(A,B),subtract(A,B)),multiply(A,B));
>
> Yes, it is "syntactic sugar" but C is just "syntactic sugar" over raw 
> assembly also.
>
>

That's a specious argument. C itself provides portability over raw
assembly. I can extend it using assembly, on all systems I use, as long
as I'm prepared to provide the assembly for all the systems my extension
will run on. I expect any C language construct to work for me on any
platform that has a C compiler.This is not syntactic sugar, this is the
language C. 

-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58428

On Tuesday, March 17, 2015 at 1:50:38 PM UTC, Greg Martin wrote:
> 
> Could you give an example? I think of operator overloading as syntactic
> sugar. Is there something that can be done with it that can't be done
> otherwise?
>
It makes sense if you allow the creation of new types, and binding
to the operators. Whist it's very difficult if not impossible to
constrain programmers so that the overloaded operators have their
mathematical meanings, you can reasonably assume that most people
will be sensible.
So we can extend an operation like taking the mean into the complex
domain, without coding a new function.
It is of course a bit dangerous. It's not clear what an integer
mean should return, for example.

You can achieve the same by requiring some sort of binding to
functions named "add" or "divide", but there's no convention for
such names.

[toc] | [prev] | [next] | [standalone]

#58430

On 2015-03-17, Greg Martin <greg.at.softsprocket@dot.com> wrote:
> On 2015-03-17, jacob navia <jacob@spamsink.net> wrote:
>> Le 16/03/2015 23:55, Bartc a écrit :
>><jacob wrote>
>>>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>>>> proposes a SINGLE mechanism that would allow users to implement their
>>>> own number types without adding the enormous complexity of integrating
>>>> all those numbers into the compiler itself.
>>>
>>> OK, so now users have to create their own DIY compiler! All the standard
>>> types are already integrated so that work is already done.
>>
>> Yes but it is done following the desires of the language implementor.
>>
>> Does he/she prefers accuracy to speed?
>>
>> The user has NO possibility to change the way those operations are done.
>>
>> And ALL other types of numbers that users need can't be programmed in C.
>
> Could you give an example? I think of operator overloading as syntactic
> sugar. Is there something that can be done with it that can't be done
> otherwise?

Infix operators are sugar for function application. 

 A*B+C -> add(mul(A, B), C)

If the operators overloadable, that is a separate question!
It means that the functions they denote can be overloaded,
which means that "add" doesn't have a fixed meaning; you can extend
add to handle new kinds of arguments and have your extension
automatically be called in the right circumstances.

That is not quite syntactic sugar.

It is syntactic, in a sense, if the overloads are statically resolved, in the
sense that the destination of the call follows from analysis of the program
text, albeit with input from the type system. Sometimes static analysis
that uses type info is still called syntactic. This is because in fact
the implementation can just do a static rewrite: the program tree can be
transformed into an equivalent one which doesn't have overloading.
Thus if the compiler knows that A and B are ints, it replace mul with
mul_int_int, which is not overloaded.

If the dispatch is dynamic, then it quite clearly isn't syntactic sugar.

[toc] | [prev] | [next] | [standalone]

#58451

On 2015-03-18, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2015-03-17, Greg Martin <greg.at.softsprocket@dot.com> wrote:
>> On 2015-03-17, jacob navia <jacob@spamsink.net> wrote:
>>> Le 16/03/2015 23:55, Bartc a écrit :
>>><jacob wrote>
>>>>> Operator overloading SIMPLIFIES THE COMPILER AND THE LANGUAGE since it
>>>>> proposes a SINGLE mechanism that would allow users to implement their
>>>>> own number types without adding the enormous complexity of integrating
>>>>> all those numbers into the compiler itself.
>>>>
>>>> OK, so now users have to create their own DIY compiler! All the standard
>>>> types are already integrated so that work is already done.
>>>
>>> Yes but it is done following the desires of the language implementor.
>>>
>>> Does he/she prefers accuracy to speed?
>>>
>>> The user has NO possibility to change the way those operations are done.
>>>
>>> And ALL other types of numbers that users need can't be programmed in C.
>>
>> Could you give an example? I think of operator overloading as syntactic
>> sugar. Is there something that can be done with it that can't be done
>> otherwise?
>
> Infix operators are sugar for function application. 
>
>  A*B+C -> add(mul(A, B), C)
>
> If the operators overloadable, that is a separate question!
> It means that the functions they denote can be overloaded,
> which means that "add" doesn't have a fixed meaning; you can extend
> add to handle new kinds of arguments and have your extension
> automatically be called in the right circumstances.
>
> That is not quite syntactic sugar.
>
> It is syntactic, in a sense, if the overloads are statically resolved, in the
> sense that the destination of the call follows from analysis of the program
> text, albeit with input from the type system. Sometimes static analysis
> that uses type info is still called syntactic. This is because in fact
> the implementation can just do a static rewrite: the program tree can be
> transformed into an equivalent one which doesn't have overloading.
> Thus if the compiler knows that A and B are ints, it replace mul with
> mul_int_int, which is not overloaded.
>
> If the dispatch is dynamic, then it quite clearly isn't syntactic sugar.

In the languages I'm aware of that allow the programmer to overload an
operator they are simply "stand-ins"  for functions or in fact functions
themselves and no different then writing out a more traditional function
hence syntactic sugar. They can give a more natural look to certain
operations, and mystify others, but they don't let the programmer do
something they can't otherwise.

Of course there are many programming languages out there and perhaps some
have a mechanism I'm not familiar with.

-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58456 — Re: What is "complexifying" C?

On 2015-03-19, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Greg Martin <greg.at.softsprocket@dot.com> writes:
>>hence syntactic sugar. They can give a more natural look to certain
>>operations, and mystify others, but they don't let the programmer do
>>something they can't otherwise.
>
>   What do you expect? - given that all common general-purpose
>   languages are Turing-complete and thus »don't let the
>   programmer do something they can't« do in any language
>   or machine language.
>
>   And being able to write
>
> x * y * Z
>
>   instead of
>
> mul( mul( x, y ), z )
>
>   does not count as »being able to do something«?
>
>   Modern programming is not about trying to be
>   Turing-complete. That goal was accomplished long ago.
>   It is all about expressiveness and maintainability. 
>

Well, sure. Let's add constructors-destructors, lambdas, closures and
range iterators to C. While we're at it lets call it Ruby++.

-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58461 — Re: What is "complexifying" C?

Le 19/03/2015 16:37, Greg Martin a écrit :
> Well, sure. Let's add constructors-destructors, lambdas, closures and
> range iterators to C. While we're at it lets call it Ruby++.

It is appalling the lack of arguments that you show here.

FORTRAN has operator overloading and did not change its name to Ruby++ 
either.

What C++ hasn't got is the art of knowing WHEN TO STOP adding features. 
What you do not get is when some features are necessary!

HOW do you solve the problem of adding new numerical types to the language?

Look at what happened with complex numbers. There are MANY ways of doing 
a complex division, if you care about speed, or accuracy or robustness, 
or other criteria. With the language solution you

1) Complexify enormously ALL the C implementations that have to add that 
feature.

2) You tie the user to its implementation decisions. He/she can't change 
the way a complex division is done.

Can you propose another solution?

And please, telling us "I don't use any new numerical types" is NOT a 
solution.

Thanks

[toc] | [prev] | [next] | [standalone]

#58462 — Re: What is "complexifying" C?

On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote:
> Le 19/03/2015 16:37, Greg Martin a écrit :
>> Well, sure. Let's add constructors-destructors, lambdas, closures and
>> range iterators to C. While we're at it lets call it Ruby++.
>
> It is appalling the lack of arguments that you show here.
>

If you insist on cutting the statements I'm responding to it's a little
hard to carry on a conversation that makes sense.

<distilled from memory> The previous poster had written that the point
of overloaded operators was greater expressiveness.</>

My point was that all of those things I listed make a language more
expressive, which is why they occur in many modern languages. Should
they be added to C as well? Why operator overloading and not the others?

> FORTRAN has operator overloading and did not change its name to Ruby++ 
> either.
>
> What C++ hasn't got is the art of knowing WHEN TO STOP adding features. 
> What you do not get is when some features are necessary!
>
> HOW do you solve the problem of adding new numerical types to the language?
>
> Look at what happened with complex numbers. There are MANY ways of doing 
> a complex division, if you care about speed, or accuracy or robustness, 
> or other criteria. With the language solution you
>
> 1) Complexify enormously ALL the C implementations that have to add that 
> feature.
>
> 2) You tie the user to its implementation decisions. He/she can't change 
> the way a complex division is done.
>
> Can you propose another solution?
>

You mean other then writing the code to do it? No. 

How does operator overloading remove the burden of writing the code? Or
are you suggesting it's not possible for programmers to operate on
complex numbers in C?

-- 
http://www.softsprocket.com

[toc] | [prev] | [next] | [standalone]

#58465 — Re: What is "complexifying" C?

Greg Martin wrote:
> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote:
>>
>> Look at what happened with complex numbers. There are MANY ways of doing
>> a complex division, if you care about speed, or accuracy or robustness,
>> or other criteria. With the language solution you
>>
>> 1) Complexify enormously ALL the C implementations that have to add that
>> feature.
>>
>> 2) You tie the user to its implementation decisions. He/she can't change
>> the way a complex division is done.
>>
>> Can you propose another solution?
>>
>
> You mean other then writing the code to do it? No.
>
> How does operator overloading remove the burden of writing the code? Or
> are you suggesting it's not possible for programmers to operate on
> complex numbers in C?

His point was in a language with operating overloading (such as C++) you 
don't have to change the core language in order to add new numeric 
types, be they complex number of otherwise.

The burden is removed from the language standard and implementation and 
in the case of complex numbers, the user gets the flexibility of 
choosing the underlying type and implementation.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web