[Click] "Graft" ports (was: Scoping/naming issues)

[Philip Prindeville]

I've been thinking about this some more...

If I have the following:

elementclass Foo {

     stuff1 ->  external-object ->  stuff2;

}

then this can be rewritten as:

elementclass Foo {
     stuff1 ->  [N] output;
     input [M] ->  stuff2;
}

f :: Foo;

f [N] ->  external-object ->  [M] f;

I'd like to propose a notational convenience called "graft" (as in a graft-point).

graft[0] would be short-hand for 1+ the highest used input, and [0] graft would be 1+ the highest used input.

(and so on for [1], [2], etc.)

We'd need a new operator for graft-points.  Maybe:

f [G]<->  [a] external-object [b]<->  [G] f;

it would be a syntactic error to mismatch subscripts for the object being grafted to.

The notation inside the elementclass would be:

elementclass Foo {
     stuff1 ->  graft [G] ->  stuff2;	// or ... [G] graft ...
}

Does that make sense?

-Philip


On 1/18/11 3:43 PM, Beyers Cronje wrote:
> The config you posted below Ian explicitly states "This would be legal:" at
> the top.  I think Ian is referring to the second config that will cause
> issues:
>
> "
> I think this should complain that fd[0] is being used twice (port
> connection error), although it may take a minute to see why that's the
> case (and would be much trickier to see in a more complex config):
> --------------------------------------
> fd::FromDevice(...);
>
> elementclass Bar {
>      fd[0] ->  Print() ->  [0]output;
> }
>
> a::Bar() ->  Discard();
> b::Bar() ->  Discard();
> --------------------------------------
> "
>
>
> On Wed, Jan 19, 2011 at 12:32 AM, Philip Prindeville<
> philipp_subx at redfish-solutions.com>  wrote:
>
>> On 1/18/11 7:34 AM, Ian Rose wrote:
>>> If I am thinking this through correctly, IMHO it wouldn't be a good idea
>>> to allow elementclasses to do this.  Reason being that in some cases you
>>> could create port connection errors merely through declaring multiple
>>> elements of your new elementclass type.  This would be an unexpected and
>>> confusing error since its impossible to do currently.  AFAIK currently
>>> there are no errors that can occur merely by *declaring* too many
>>> elements of some type.  So this would introduce a whole new category of
>>> error.  Some examples:
>>>
>>> This would be legal:
>>> --------------------------------------
>>> fd::FromDevice(...);
>>>
>>> elementclass Bar {
>>>        fd[0] ->   Print() ->   [0]output;
>>> }
>>>
>>> a::Bar() ->   Discard();
>>> --------------------------------------
>>>
>>> I think this should complain that fd[0] is being used twice (port
>>> connection error), although it may take a minute to see why that's the
>>> case (and would be much trickier to see in a more complex config):
>> Sorry, not seeing why the above case represents using the port twice...
>>
>>
>>> --------------------------------------
>>> fd::FromDevice(...);
>>>
>>> elementclass Bar {
>>>        fd[0] ->   Print() ->   [0]output;
>>> }
>>>
>>> a::Bar() ->   Discard();
>>> b::Bar() ->   Discard();
>>> --------------------------------------
>>>
>>> In order to cause this same error currently (without the proposed
>>> elementclass enhancement) you'd have to do this, which I think makes the
>>> error more obvious:
>>> --------------------------------------
>>> fd::FromDevice(...);
>>>
>>> elementclass Bar {
>>>        input[0] ->   Print() ->   [0]output;
>>> }
>>>
>>> fd[0] ->   a::Bar() ->   Discard();
>>> fd[0] ->   b::Bar() ->   Discard();
>>> --------------------------------------
>>>
>>>
>>> Just my $0.02.
>>>
>>> - Ian
>>>
>>>
>>> On 01/17/2011 07:55 PM, Philip Prindeville wrote:
>>>> Yeah, it especially makes sense to have arpfoo be global if it needs to
>> be accessible from two different elementclass's, one that deals with the IP
>> flow (input [0] and output [0]) and another one that deals strictly with the
>> ARP request/reply flow (input [1] and output [1]).
>>>> Someone else will have to come up with the patches...  I've not yet
>> dabbled in the code itself.
>>>>
>>>> On 1/17/11 4:35 PM, Eddie Kohler wrote:
>>>>> Hi Philip,
>>>>>
>>>>> I can see why you thought compound elements would work that way, but
>> they don't.  They are very strictly encapsulated: all connections to other
>> elements must take place through explicit inputs and outputs.
>>>>> I admit it would make sense to do it the way you've imagined.  Patches
>> welcome...
>>>>> Eddie
>>>>>
>>>>>
>>>>> On 1/15/11 2:53 PM, Philip Prindeville wrote:
>>>>>> I've got a configuration where I do:
>>>>>>
>>>>>> ...
>>>>>> arpfoo :: ARPQuerier(...);
>>>>>>
>>>>>> elementclass Bar {
>>>>>> ...
>>>>>>          class :: classifier(...);
>>>>>> ...
>>>>>>           class [2] ->      [1] arpfoo;
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>>
>>>>>> but it complains that "unknown element class 'arpfoo'" in a few
>> places, and that input 1 isn't used...
>>>>>> So I'm confused.  Everything is scoped globally... even stuff defined
>> within an elementclass gets scoped globally.
>>>>>> Why then can't I access a global variable from within an
>> elementclass's scope?
>>>>>> What am I missing?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Philip
>>