hi -

i am just looking at the new array methods, and i see that we have now 
two quite different opcodes which are both called "product":

ares product asig1, asig2 [, asig3] [...]
kres/ires product karr[]/iarr[]

should this same name for two quite different opcodes be better avoided?

best -

+1 for Opcode overloading when possible.


On 29/06/17 16:53, John ff wrote:
> Seems ok to me.  Both calculate a product
>
> ⁣Sent from TypeApp ​
>
> On 29 Jun 2017, 20:33, at 20:33, joachim heintz  wrote:
>> hi -
>>
>> i am just looking at the new array methods, and i see that we have now 
>> two quite different opcodes which are both called "product":
>>
>> ares product asig1, asig2 [, asig3] [...]
>> kres/ires product karr[]/iarr[]
>>
>> should this same name for two quite different opcodes be better
>> avoided?
>>
>> best -

yes, we tend to try and use overloading when we can

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 29 Jun 2017, at 21:03, Guillermo Senna  wrote:
> 
> +1 for Opcode overloading when possible.
> 
> 
>> On 29/06/17 16:53, John ff wrote:
>> Seems ok to me.  Both calculate a product
>> 
>> ⁣Sent from TypeApp ​
>> 
>>> On 29 Jun 2017, 20:33, at 20:33, joachim heintz  wrote:
>>> hi -
>>> 
>>> i am just looking at the new array methods, and i see that we have now 
>>> two quite different opcodes which are both called "product":
>>> 
>>> ares product asig1, asig2 [, asig3] [...]
>>> kres/ires product karr[]/iarr[]
>>> 
>>> should this same name for two quite different opcodes be

ok, i know what you mean.

but should then there only one manual page?  this puzzled me: i tried to 
understand how to use the new product for arrays, and got on the other 
manual page for product (multiplying to audio signals).

or maybe a hint and link from one page to the other?

best -
	joachim


On 29/06/17 22:07, Victor Lazzarini wrote:
> yes, we tend to try and use overloading when we can
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 29 Jun 2017, at 21:03, Guillermo Senna  wrote:
>>
>> +1 for Opcode overloading when possible.
>>
>>
>>> On 29/06/17 16:53, John ff wrote:
>>> Seems ok to me.  Both calculate a product
>>>
>>> ⁣Sent from TypeApp ​
>>>
>>>> On 29 Jun 2017, 20:33, at 20:33, joachim heintz  wrote:
>>>> hi -
>>>>
>>>> i am just looking at the new array methods, and i see that we have now
>>>> two quite different opcodes which are both called "product":
>>>>
>>>> ares product asig1, asig2 [, asig3] [...]
>>>> kres/ires product karr[]/iarr[]
>>>>
>>>> should this same name for two quite different opcodes be better
>>>> avoided?
>>>>
>>>> best -

A single page is possibly the right thing to do.
========================
Prof. Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 30 Jun 2017, at 07:12, joachim heintz  wrote:
> 
> ok, i know what you mean.
> 
> but should then there only one manual page?  this puzzled me: i tried to understand how to use the new product for arrays, and got on the other manual page for product (multiplying to audio signals).
> 
> or maybe a hint and link from one page to the other?
> 
> best -
> 	joachim
> 
> 
> On 29/06/17 22:07, Victor Lazzarini wrote:
>> yes, we tend to try and use overloading when we can
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>>> On 29 Jun 2017, at 21:03, Guillermo Senna  wrote:
>>> 
>>> +1 for Opcode overloading when possible.
>>> 
>>> 
>>>> On 29/06/17 16:53, John ff wrote:
>>>> Seems ok to me.  Both calculate a product
>>>> 
>>>> ⁣Sent from TypeApp ​
>>>> 
>>>>> On 29 Jun 2017, 20:33, at 20:33, joachim heintz  wrote:
>>>>> hi -
>>>>> 
>>>>> i am just looking at the new array methods, and i see that we have now
>>>>> two quite different opcodes which are both called "product":
>>>>> 
>>>>> ares product asig1, asig2 [, asig3] [...]
>>>>> kres/ires product karr[]/iarr[]
>>>>> 
>>>>> should this same name for two quite different opcodes be better
>>>>> avoided?
>>>>> 
>>>>>