On Fri, 07 Aug 2009 18:57:12 +0200, Michel Fortin <michel.fortin@michelf.com> wrote:

> On 2009-08-07 12:33:09 -0400, Miles <_______@_______.____> said:
>
>> Lars T. Kyllingstad wrote:
>>> Neither of the natural candidates, a^b and a**b, are an option, as they
>>> are, respectively, already taken and ambiguous.
>>  I think that a ** b can be used, is not ambiguous except for the
>> tokenizer of the language. It is the same difference you have with:
>>    a ++ b  -> identifier 'a', unary operator '++', identifier 'b' (not
>> parseable)
>>    a + + b  -> identifier 'a', binary operator '+', unary operator '+',
>> identifier 'b' (parseable)
>
> But to be coherent with a++ which does a+1, shouldn't a** mean a to the power 1 ?

No. As we can see, ++ is the concatenation of two addition operators, so
the equivalent for exponential would be a****, a^^^^, or a*^*^. :p

-- 
  Simen

Miles wrote:
> Lars T. Kyllingstad wrote:
>> Neither of the natural candidates, a^b and a**b, are an option, as they
>> are, respectively, already taken and ambiguous.
> 
> I think that a ** b can be used, is not ambiguous except for the
> tokenizer of the language. It is the same difference you have with:
> 
>   a ++ b  -> identifier 'a', unary operator '++', identifier 'b' (not
> parseable)
> 
>   a + + b  -> identifier 'a', binary operator '+', unary operator '+',
> identifier 'b' (parseable)
> 
> I don't know anyone who writes ** to mean multiplication and
> dereference, except when obfuscating code. People usually prefer adding
> a whitespace between both operators, for obvious readability purposes.
> 
> I think it is perfectly reasonable to deprecate current usage of '**'
> for the next release, and a few releases later, make '**' a new
> operator. I doubt anyone would notice.

That doesn't work, because you still get new code being converted from C. It can't look the same, but behave differently.

> 
> Other examples:
> 
>   a-- - b
>   a - --b
> 
>   a && b
>   a & &b

You didn't respond to my assertion: even if you _could_ do it, why would you want to? ** sucks as an exponential operator. I dispute the contention that ** is a natural choice. It comes from the same language that brought you  IF X .NE. 2

Don wrote:
> That doesn't work, because you still get new code being converted from C. It can't look the same, but behave differently.

int* a, b;

Ooops...

grauzone wrote:
> Don wrote:
>> That doesn't work, because you still get new code being converted from C. It can't look the same, but behave differently.
> 
> int* a, b;
> 
> Ooops...

Touche. C declaration syntax is dreadful.

grauzone wrote:
> Don wrote:
>> That doesn't work, because you still get new code being converted from C. It can't look the same, but behave differently.
> 
> int* a, b;
> 
> Ooops...

Since that changes the type of b, it's at least likely to give you a compile error.

Although I suppose you could say the same thing about a**b...

Don wrote:
> Miles wrote:
>> Lars T. Kyllingstad wrote:
>>> Neither of the natural candidates, a^b and a**b, are an option, as they
>>> are, respectively, already taken and ambiguous.
>>
>> I think that a ** b can be used, is not ambiguous except for the
>> tokenizer of the language. It is the same difference you have with:
>>
>>   a ++ b  -> identifier 'a', unary operator '++', identifier 'b' (not
>> parseable)
>>
>>   a + + b  -> identifier 'a', binary operator '+', unary operator '+',
>> identifier 'b' (parseable)
>>
>> I don't know anyone who writes ** to mean multiplication and
>> dereference, except when obfuscating code. People usually prefer adding
>> a whitespace between both operators, for obvious readability purposes.
>>
>> I think it is perfectly reasonable to deprecate current usage of '**'
>> for the next release, and a few releases later, make '**' a new
>> operator. I doubt anyone would notice.
> 
> That doesn't work, because you still get new code being converted from C. It can't look the same, but behave differently.
> 
>>
>> Other examples:
>>
>>   a-- - b
>>   a - --b
>>
>>   a && b
>>   a & &b
> 
> You didn't respond to my assertion: even if you _could_ do it, why would you want to? ** sucks as an exponential operator. I dispute the contention that ** is a natural choice. It comes from the same language that brought you  IF X .NE. 2


I've been translating a lot of FORTRAN code to D lately, and it's amazing what one can get used to reading. Even X.NE.2. :) The worst part is translating 1-based array indexing to base 0 (it should be a simple transformation, but those old FORTRAN coders have made damn sure that isn't always the case...), and unraveling horrible spaghetti code like this:

  100 if(abserr.eq.oflow) go to 115
      if(ier+ierro.eq.0) go to 110
      if(ierro.eq.3) abserr = abserr+correc
      if(ier.eq.0) ier = 3
      if(result.ne.0.0d+00.and.area.ne.0.0d+00) go to 105
      if(abserr.gt.errsum) go to 115
      if(area.eq.0.0d+00) go to 130
      go to 110
  105 if(abserr/dabs(result).gt.errsum/dabs(area)) go to 115

In the end I just had to admit defeat and define a few labels...

-Lars

Don wrote:
> You didn't respond to my assertion: even if you _could_ do it, why would you want to? ** sucks as an exponential operator. I dispute the contention that ** is a natural choice. It comes from the same language that brought you  IF X .NE. 2

There are too many languages that support ** as an exponentiation operator, that is the reason ** is a likely candidate. Your reasoning seemed to be:

- Fortran is bad;
- Fortran had ** as its exponentiation operator;
- So, ** is bad as an exponentiation operator.

I don't care for ** or .NE., really. I don't like * as a multiplication operator, in fact. I'd rather have × as multiplication, ↑ as exponentiation, ∧ as logical and, ∨ as logical or, ¬ as a logical not, = as equality, ≠ as inequality and ← as assignment.

I don't know why, but every time I say this, it brings all sorts of controversies and euphoric reactions.

Miles wrote:
> Don wrote:
>> You didn't respond to my assertion: even if you _could_ do it, why would
>> you want to? ** sucks as an exponential operator. I dispute the
>> contention that ** is a natural choice. It comes from the same language
>> that brought you  IF X .NE. 2
> 
> There are too many languages that support ** as an exponentiation
> operator, that is the reason ** is a likely candidate. Your reasoning
> seemed to be:
> 
> - Fortran is bad;
> - Fortran had ** as its exponentiation operator;
> - So, ** is bad as an exponentiation operator.

Not at all! I'm attacking the fallacy that "** must be a good choice because so many languages use it".

* The ONLY reason other languages use ** is because Fortran used it.
* Fortran used ** because it had no choice, not because it was believed to be good.
* We have choices that Fortran did not have. The best choice for Fortran is not necessarily the best choice for D.

Note that there are no C-family languages which use ** for exponentiation, so there isn't really a precedent.

However, the syntax is really not the issue. The issue is, is there sufficient need for a power operator (of any syntax)?


> I don't care for ** or .NE., really. I don't like * as a multiplication
> operator, in fact. I'd rather have × as multiplication, ↑ as
> exponentiation, ∧ as logical and, ∨ as logical or, ¬ as a logical not, =
> as equality, ≠ as inequality and ← as assignment.
> 
> I don't know why, but every time I say this, it brings all sorts of
> controversies and euphoric reactions.
Lack of keyboards.

Don Wrote:
> However, the syntax is really not the issue. The issue is, is there sufficient need for a power operator (of any syntax)?

std.math.pow only support floating point number http://d.puremagic.com/issues/show_bug.cgi?id=2973

If we can't make the power function more powerful, yes, we need a new operator.

On 2009-08-10 13:56:53 -0400, Miles <_______@_______.____> said:

> Don wrote:
>> You didn't respond to my assertion: even if you _could_ do it, why would
>> you want to? ** sucks as an exponential operator. I dispute the
>> contention that ** is a natural choice. It comes from the same language
>> that brought you  IF X .NE. 2
> 
> There are too many languages that support ** as an exponentiation
> operator, that is the reason ** is a likely candidate. Your reasoning
> seemed to be:
> 
> - Fortran is bad;
> - Fortran had ** as its exponentiation operator;
> - So, ** is bad as an exponentiation operator.
> 
> I don't care for ** or .NE., really. I don't like * as a multiplication
> operator, in fact. I'd rather have × as multiplication, ↑ as
> exponentiation, ∧ as logical and, ∨ as logical or, ¬ as a logical not, =
> as equality, ≠ as inequality and ← as assignment.

HyperTalk used to have <> for inequality, but ≠ worked too. You could write >= for greater or equal, but ≥ worked too. That said, having = as equality in a C-derived language is somewhat problematic.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/