Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p><strong><em>(Note: this is a summary of the discussion that took place in possibly more detail in the comments section of another answer on this question.)</em></strong></p> <p>It turns out that the problem here <em>is</em> that the <code>implicit</code> parameter is not first in <code>runAny</code>, but not because the implicit binding mechanism is ignoring it: instead, the issue is that the type parameter <code>Output</code> is not bound to anything, and needs to be indirectly inferred from the type of the <code>run</code> implicit parameter, which is happening "too late".</p> <p>In essence, the code for "undetermined type parameters" (which is what <code>Output</code> is in this circumstance) only gets used in situations where the method in question is considered to be "implicit", which is determined by its direct parameter list: in this case, <code>runAny</code>'s parameter list is actually <em>just</em> <code>(input :Input)</code>, and isn't "implicit".</p> <p>So, the type parameter for <code>Input</code> manages to work (getting set to <code>Int::HNil</code>), but <code>Output</code> is simply set to <code>Nothing</code>, which "sticks" and causes the type of the <code>run</code> argument to be <code>Int::HNil=&gt;Object=&gt;Nothing</code>, which is not satisfiable by <code>runNil</code>, causing <code>runAny</code>'s type inferencing to fail, disqualifying it for usage as an implicit argument to <code>runAll</code>.</p> <p>By reorganizing the parameters as done in my modified code sample #2, we make <code>runAny</code> itself be "implicit", allowing it to first get its type parameters fully determined before applying its remaining arguments: this happens because its implicit argument will first get bound to <code>runNil</code> (or <code>runAny</code> again for more than two levels), whose return type will get taken/bound.</p> <p>To tie up the loose ends: the reason that the code sample #3 worked in this situation is that the <code>Output</code> parameter wasn't even required: the fact that it was bound to <code>Nothing</code> didn't affect any subsequent attempts to bind it to anything or use it for anything, and <code>runNil</code> was easily chosen to bind to its version of the <code>run</code> implicit parameter.</p> <p>Finally, code sample #4 was actually degenerate, and shouldn't even have been considered to "work" (I had only verified that it compiled, not that it generated the appropriate output): the data types of its implicit parameters were so simplistic (<code>Input=&gt;Output</code>, where <code>Input</code> and <code>Output</code> were actually intended to be the same type) that it would simply get bound to <code>conforms:&lt;:&lt;[Input,Output]</code>: a function that in turn acted as the identity in this circumstance.</p> <p><em>(For more information on the #4 case, see this apparently dead-on related question: <a href="https://stackoverflow.com/questions/5377492">problem with implicit ambiguity between my method and conforms in Predef</a>.)</em></p>
    singulars
    1. This table or related slice is empty.
    1. POTwo seemingly identical semantics: one binds implicitly, the other does not
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USJay Freeman -saurik-
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POTwo seemingly identical semantics: one binds implicitly, the other does not
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload