Finding all paths in a cell and increase width

thinPaths=setof(shape cv~>shapes member(shape~>objType '("path" "pathSeg")) && shape~>width<0.1)
thinPaths~>width=0.1

This will find all the shapes which are either path or pathSeg (the path segments you mention, which are the more modern way of handling connectivity) which are narrower than 0.1um. Then having found that list, it will set the width to 0.1um.

Regards,

Andrew.

 Thank you for your fast and helpful reply, Andrew. This solution works. The only small change I made was to constrain it to the M1 layer so I added the condition:

 thinPaths=setof(shape cv~>shapes member(shape~>objType '("path" "pathSeg")) && shape~>width<0.1 && shape~>layerName=="M1")

Another example of the map(filter(...)) pattern!  :)

One of SKILL's more clever innovations is the inclusion of tradtional logical/set-theoretic operations implemented as variable-binding macros:

• Quantifiers: forall, exists
• Filter: setof
• Map: [foreach] mapcar
• Reduce: [foreach] mapcan

(Well, mapcan really only covers the special case of reduce where the operator is append, but it is one of the most common use cases.)

These macros really add a lot to the expressiveness of SKILL, and since they bind a local variable for you automatically, they often save you from using let/prog to declare one yourself.  E.g., Andrew's code above could also be written:

foreach(thinPath setof(shape cv->shapes member(shape->objType '("path" "pathSeg")) && shape->width<0.1)
    thinPath->width = 0.1
)

Which automatically scopes "thinPath" within the foreach(mapc...), at the cost of an additional level of nesting.

I could also have used the implicit foreach mapcar of the ~> operator (rather than adding an explicit foreach like you did) by doing:

but for the purposes of explaining it (particular to those who are less familiar with a more functional style of programming), I intentionally broke it into two steps.

Andrew.

Andrew Beckett said:

for the purposes of explaining it (particular to those who are less familiar with a more functional style of programming), I intentionally broke it into two steps.

Yeah, I regularly do the same for my co-workers.

Andrew Beckett said:

I could also have used the implicit foreach mapcar of the ~> operator (rather than adding an explicit foreach like you did) by doing:

setof(shape cv~>shapes member(shape~>objType '("path" "pathSeg")) && shape~>width<0.1 && shape~>layerName=="M1")~>width=0.1

For years I always wrote my code this way because it was shorter. :)  It's great for one-liners, but it doesn't scale well.  Sometimes I'd end up with code like this:

foreach(
    foreach(
        foreach(...
           ...
        )
    )~>stuff
)

The infix ~> is just sort of awkwardly hanging there in the middle of all this prefix nesting.

Two years ago I switched to using Lisp style so I could take advantage of Emacs' Lisp mode (since I was too lazy to write one for infix SKILL), so now I write

 
(foreach ...
  (getSGq (foreach ...
            (foreach ...
               ...))
          stuff))
            

Which I think more clearly reflects the nesting, since it's consistently prefix.

Using Lisp style also avoids wasting vertical space. I like the way the Emacs Lisp Reference Manual said it:

Don't make a habit of putting close-parentheses on lines by themselves; Lisp programmers find this disconcerting.

tweeks said:

Two years ago I switched to using Lisp style so I could take advantage of Emacs' Lisp mode (since I was too lazy to write one for infix SKILL)

I too tend to write in Lisp style (and have done so for 20 years or so), for a few reasons. One was that I used to write a lot of C code, and SKILL was different enough from C that I kept making mistakes. Secondly I was somewhat familiar with Lisp and writing in Lisp syntax tended to encourage me to think in terms of Lisp ways of doing things. Thirdly "vi" has a lisp mode (I'm a vi rather than emacs user). Fourthly I'm a bit perverse...

That said, I do tend to revert to C style when I am trying to illustrate examples or ideas, because I know the majority of the SKILL user-base uses C style and I don't want them to be put off by the "Lots of Irritating and Superflous Parentheses"...

tweeks said:

Don't make a habit of putting close-parentheses on lines by themselves; Lisp programmers find this disconcerting.

That said, I do tend to shy away from excessive numbers of close parentheses on the same line - I'm not rigid on this, but I try to consider readability over compactness...

Regards,

Andrew.