Re: Re: When are scala macros expanded?

Tom Switzer <[email protected]>
Newsgroups gmane.comp.lang.scala
Message-ID <CAMRK40Y=AS47Rfqg0LM8mr-=MLGU8p6bP01PyGQN=AXn1+yAVA@mail.gmail.com>
Hi Jeremy,

Unfortunately, what you want is not possible (with macros or without). The
compiler cannot lookup the implicit at the call site, since it has no idea
that `foo` requires that implicit. You must make this explicit by adding an
implicit parameter to the method foo. I know you want to avoid this, but
you really only have 2 options here (assuming you want to follow this
approach):

  1. Capture the implicit at the call site with an implicit parameter,
  2. Make the implicit a member of your trait and capture an instance when
the class is instantiated.

You'll have to make a trade off here. It's one many of us have made before.
That said, I suspect you may be able to solve your problem in a way you
want by using sufficiently fine-grained type classes.

Cheers,
Tom

On Thu, Jun 18, 2015 at 10:32 AM, Jeremy Smith <[email protected]>
wrote:

> Hi Andrew,
>
> I understand that this is an edge case, and probably not a good idea to
> begin with.  However, it's still an interesting question: if a method calls
> implicitly[Something], but that method is never called, can you consider
> the implicit Something to be required?  Should compilation then fail if it
> isn't provided?  The compiler has no problem checking for the implicit -
> the issue (if you can call it that) is that the compiler checks it eagerly
> during compilation of the class, not at the call site of the method which
> calls implicitly[Something].
>
>
> On Wednesday, June 17, 2015 at 8:10:44 PM UTC-7, Andrew Phillips wrote:
>>
>> Hi Jeremy
>>
>> Without having spent much time trying to come up with a creative
>> approach, I would be surprised if what you're trying to do were possible.
>>
>> If I understand your problem statement correctly, you're trying to add a
>> condition to a method defined on an interface "after the fact:" an
>> additional (implicit) parameter, in this case. Yet this condition is only
>> supposed to be checked for by the compiler if the implementation class of
>> the interface happens to be *your* specific class. Which would seem to
>> require that the compiler know up front what the *runtime* class of the
>> implementation will be.
>>
>> If I write:
>>
>> val myObj: SomeInterface = ...
>> myObj.foo(...)
>>
>> I would imagine that the compiler can *only* verify that my attempt to
>> call foo is compatible with the definition of foo in SomeInterface,
>> i.e. the static type of myObj. I don't see how, at compile time, we
>> would be able to say: "Ah, if myObj in this case happens to be an
>> instance of SpecialImplOfSomeInterface, we need to check for an extra
>> implicit/parameter/parameter list/whatever."
>>
>> Curious to see what other participants in this thread will come up with!
>>
>> Regards
>>
>> ap
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "scala-language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.