GHtxt: I'm trying a little experiment and need your help.

Replies to This Discussion

Permalink Reply by David Rutten on May 2, 2014 at 2:04am

May I suggest that the names of outputs and inputs are both included on either side of a connecting wire in case of components:

[Point=SetMultiplePoints]-->[V][Polyline]

[Polyline][Pl]-->[C][Fillet Distance]

[Slider=0..1..10]-->[D][Fillet Distance]

[Slider=1..5..20]-->[F][Unit Z]

[Fillet Distance][C]-->[B][Extrude]

[Unit Z][V]-->[D][Extrude]

This still leaves the problem of having more than one of a single component on the canvas. Referral can be made unambiguous by simply picking the most recent component with the same name. But how do you indicate you want a second Polyline component?

Possible solutions:

1. Separators in the text:
   
   [Point=SetMultiplePoints]-->[V][Polyline]
   ----------------------------------
   [Point=SetMultiplePoints]-->[V][Polyline]
   
   
2. Keywords or symbols to indicate the creation of a new component rather than the re-use of an existing one:
   
   new [Point=SetMultiplePoints]--> new [V][Polyline]
   new [Point=SetMultiplePoints]--> new [V][Polyline]
   

(2) is a lot more flexible and (1) may not work at all as it will prevent any reuse above and below the separator.

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on May 2, 2014 at 2:51am

Hi David, thanks for the input

May I suggest that the names of outputs and inputs are both included on either side of a connecting wire

Is this just to remove ambiguity?

Also my logic was to have [] as components () as parameters and <> as modifiers. Is there a reason to have [] for both components and parameters in your example?

I think option 2 for new components is a good one.

@Ángel thanks for the support! :)

Permalink Reply by David Rutten on May 2, 2014 at 4:10am

One of the problems is that there is no restriction on what a component can be called. Every character is allowed, even ones not typically found on western keyboards. Parenthesis are used in several places already, so I'd prefer to not have them be meaningful in this notation. Curly and Square brackets seem less common and are thus better choices for a new language like this.

From programming you could even take the dot notation to separate out component and parameter names. So instead of:

[Polyline][Pl]-->[C][Fillet Distance]

You'd get:

[Polyline.Pl] --> [Fillet Distance.C]

I actually like that better, as it even allows one to remove the brackets altogether, giving even more compact notation:

Polyline.Pl --> Fillet Distance.C

In this case only the "-->" string has meaning so the chances of this notation colliding with existing names is even smaller.

If the parameters can be implied (for example because there only is one, or because the types are identical) then you can leave the parameter names off, but that would be shorthand.

Concerning modifiers, they could be written in a very similar notation if you're willing to have them on separate lines:

Polyline.Pl --> Fillet Distance.C

Polyline.Pl <-- Simplify, Reparameterize

What do you think?

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on May 2, 2014 at 4:36am

I had considered the dot notation to be contained within the [] but as sometimes I write a simple problem on one line I thought this could be simplified by having Inputs prefixed and outputs postfixed.

But if its always Left of --> is outputs and Right of --> inputs then it wouldn't matter.

The Modifiers i wanted to distinguish between the components of the same name.

<Expression> vs [Expression]

<Flatten> vs [Flatten]

<Graft> vs [Graft]

etc.

therefore there wouldn't be a confusion for eg.

Polyline.Pl --> Fillet Distance.C

Polyline.Pl <-- Simplify

and

Polyline.Pl --> Fillet Distance.C

Polyline.Pl --> Simplify

Permalink Reply by David Rutten on May 2, 2014 at 7:07am

After a discussion with the resident language expert I have some other suggestions:

• The creation of a new component is implied the first time it is used, however it can also be specified using a special command:
  create: Divide Curve, Voronoi, Area, Circle
• If there are multiple instances of a single component, then you can assign them IDs (according to Ángel's suggestion) using square brackets:
  create: Divide Curve, Circle[1], Circle[2]
  You can use numbers or words, whatever you want to identify a component.
• Parameters are written in parenthesis, in front if they are input parameters, trailing if they are outputs:
  Voronoi(C) --> (G)Area
  This will conflict somewhat with components which already use parenthesis in their name, but we can simply consider the first or last parenthesis pair to indicate the parameter. In other words, the ambiguity can be resolved because all alternative interpretations are invalid.
• K didn't like my usage of an inverse arrow ( <-- ) to assign properties, I didn't like her suggestion of a different inverse arrow ( <== ). The equals symbol seems to be a halfway decent alternative, eventhough K still doesn't like it:
  Voronoi = Preview:Off
• All sorts of properties can be assigned using this notation, including name, position, enabledness etc.
• We haven't decided on a good way to assign initial properties quickly. Your first suggestion [Slider=60] may work in conjunction with the create statement, but it is somewhat awkward. I suppose the logical way for this to work is to simply type:
  slider = 0..10..50
  using the shorthand notation for creating a new object (by mentioning it out of the blue) and immediately assigning a property to it.

Does this approach violate some of the goals you had in mind originally?

--

David Rutten

david@mcneel.com

Permalink Reply by Danny Boyes on May 2, 2014 at 7:36am

Create: Divide Curve, Circle[1], Circle[2]

fits in really well with Shift + Component Selection

I cannot see why the Equals sign doesn't fit well for this purpose. The only alternative I can think of is "@" to stand for assign but I still don't like that in case of (a). Also @user seems to be established in meta sense.

It seems to be gaining speed :) Thank you for your help and thank K for her linguistic prowess. When will we hear from the owl herself? Or is she trying to stay sanitized to stay on top of her game for the Help Topics

Permalink Reply by djordje on May 1, 2014 at 5:11pm

Very interesting Danny !!

• ‹ Previous
• 1
• 2
• Next ›
• Page