[m-users.] Ambiguous overloading error, with_type suggested

[Sean Charles (emacstheviking)]

Hi Zoltan,

> The ambiguity comes in because list.filter has both an arity 3 and an arity 4 version,
> and the compiler does not know which one you are trying to partially apply.

BINGO! I *love* exchanges like this because these are the times you truly learn something!
The irony is that is was *because* of my morning coffee that I dug deep enough for us both to get to the solution to the puzzle.
The software industry would collapse without coffee, and pizza, probably.

Thanks again Zoltan, a pleasure as always, I feel really happy now that the veil has lifted and I understand both the initial problem I had and my workarounds and I have now put the code back to how I wanted it in the first place but with —understanding— , the thing that sets machines apart from humans.

Excellent!
:)
Sean


> On 13 Jun 2021, at 09:51, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
> 
> 
> 2021-06-13 18:43 GMT+10:00 "Sean Charles (emacstheviking)" <objitsu at gmail.com>:
>> Your response says that the function form takes a function as the first arg but they all take a closure as the first argument, at least from looking  at the source code for 20.06.01.
> 
> You are right, I was wrong: all versions of list.filter take a pred as the first arg.
> The ambiguity comes in because list.filter has both an arity 3 and an arity 4 version,
> and the compiler does not know which one you are trying to partially apply.
> 
> Normally, the ambiguity is resolved when you use the result of the partial application
> in a context that matches only one of the alternatives. However, in your original code,
> the *only* thing you did with Tokens was convert it to a string, using string.string,
> and that can be done for *any* type. That was what the original ambiguity message
> was about. (I should not have sent my first reply before by first morning dose
> of caffeine :-)
> 
>> If I understand your response correctly, you are saying that Tokens is in fact bound to a closure presumably because I have failed to fully satisfy a func/pred form and ended up with, in Haskell terminology, a partial application?
> 
> Yes.
> 
>> Changing my code to read:
>> 
>> 	list.filter(Pr. Tk, Tokens)
>> 
>> compiles as the first predicate form was satisfied, changing it to this:
>> 
>>    list.filter(Pr, Tk, Tokens, Comments),
>> 
>> also compiles as the second predicate form is used (this might be useful in the future actually :) and this code:
>> 
>>    Tokens = list.filter(Pr, Tk)
>> 
>> obviously still fails to compile and I still fail to understand. 
> 
> I hope the above explains it.
> 
> Zoltan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/users/attachments/20210613/d4f59970/attachment.html>