-> ~> difference???

Hello,
what is the difference between -> and ~> operator??

Giuseppe

 

It's all to do with how they work with lists. For most objects they are
interchangeable, but for lists they are not.

The straight arrow (->) with a list on the left hand side, treats the list as
a disembodied property list. That means that it would be a list of the form:

(dummyEntry key1 val1 key2 val2 key3 val3)

dummyEntry is commonly nil, and the keys are symbols. You can then do:

dpl->key2

and it will return val2.

The straight arrow will (try) to interpret a list as a disembodied property
list, even if it isn't...


The squiggle (~>) with a list on the left side does an implicit
foreach(mapcar...) - i.e. doing:

lstOfObjs~>myprop

will try to get the value of the myprop attribute on each object in the list,
and return that. In other words, if you have:

lstOfObjs=list(obj1 obj2 obj3 obj4)

lstOfObjs~>myprop

is like doing:

list(obj1~>myprop obj2~>myprop obj3~>myprop obj4~>myprop)

or put another way:

foreach(mapcar obj lstOfObjs obj~>myprop)

So with squiggle, each entry in the list needs to be able to have a ~>
operator on it for this to work.

Hope that clears it up!

Regards,

Andrew.

 

Thank you! Very clear. ;-)

Giuseppe

 

Andrew, ~> is used in a no of places in your reply where, I think, ->
should have been used. Did you reply when you were sleepy

list(obj1->myprop obj2->myprop obj3->myprop obj4->myprop)

foreach(mapcar obj lstOfObjs obj->myprop)

So with squiggle, each entry in the list needs to be able to have a ->
operator on it for this to work.

Regards,
Suresh

 

Suresh,

No, what I said was correct. In fact what you suggested as replacements
were incorrect.

For example, if it worked as you suggested, then doing:

listOfDpls~>myprop

would get the value of myprop from each dpl within the list of dpls, since
-> is a valid operator in a DPL. But that's not what happens.

If you use ~> on a list, then each object in the list must in itself accept
~>.

Regards,

Andrew.

 

chosen excerpts from SKILL user guide:

Arrow (->) Operator
-------------------
The arrow (->) operator can be applied to disembodied property lists, defstructs, association
tables, and user types (special application-supplied types) to access property values. [...]
---

Squiggle Arrow (~>) Operator
----------------------------
[...] It works the same way as an arrow operator when applied directly to an object, but it can
also accept a list of such objects. It walks the list applying the arrow operator whenever it
finds an atomic object.
---

The ambiguity lies maybe in the definition of "atomic" object :

Atoms
-----
An atom is any data object that is not an aggregate of other data objects. In other words, atom
is a generic term covering data objects of all scalar data types. [...]
---

Well this is not 100% clear... to my opinion, disembodied property lists, defstructs, association
tables, and user types do not seem to be scalar, hence they are not atoms. because to my knowledge
scalar is usually used to designate stuff that can be represented by a single number.

according to this, squiggle arrow shouldn't work like on a list of DPLs, just like Andrew said,
because DPLs are not atoms. shoudn't work neither on lists of other non-scalar types, but it
DOES work on lists of user types, defstructs, assoc.tables, and mixed (see tests below).

so what? apparently, DPLs are not considered as atoms (in fact they are lists, aren't they?) but
the other mentioned types ARE considered as atoms. If i wanted to be picky i'd say this is not clear
from the definition of atom in the manual. and i'd pull out the definition of a scalar from a
dictionary...

or maybe am i missing something?

cheers,

stéphane


---
Here are a few tests:

DPLs:
a='(nil x 1 y 2)
b='(nil x 3 y 4)
c=list(a b)

a->x => 1 OK
a->y => 2 OK
a~>x => *Error* get/getq: first arg must be either symbol, list, defstruct or user type - 1
c~>x => (nil nil)

USER TYPES:

wnd1=hiGetCurrentWindow()
wnd2=hiGetCurrentWindow() /* after selecting another window */
c=list(wnd1 wnd2)

wnd1->cellView => db:201460780
wnd1~>cellView => db:201460780
c->cellView => nil
c~>cellView => (db:201460780 db:201460780)

DEFSTRUCTS:

defstruct( point x y )
pt1 = make_point(?x 1 ?y 2)
pt2 = make_point(?x 3 ?y 4)
c=list(pt1 pt2)

pt1->x => 1
pt1~>x => 1
c->x => nil
c~>x => (1 3)

ASSOC TABLES:

p = makeTable( 'mytable 0 )
p['x]=1 p['y]=2
q = makeTable( 'mytable 0 )
q['x]=2 q['y]=3
c=list(p q)

p->x => 1
p~>x => 1
c->x => nil
c~>x => (1 1)

MIXED:
c=list( pt1 pt2 p q )
c~>x => (1 3 1 3)

 

There's a difference between the mathematical concept of a scalar
(element of a field or numerical quantity) and the way computer
scientists abuse the term scalar. The latter depends on the person
being quoted. In this case, "scalar" happens to mean "not a list."

In particular, ~> will not work on vectors (which is probably wrong, but
changing such behavior is not trivial).

Regardless of what the documentation states, what it infers, or how it
reads between the lines, Andrew is correct here.[*] To verify, I just
checked the SKILL source, and the code for ~> is (in pseudocode):

x~>y:
if x is a list:
mapcar z~>y for every element z in x
otherwise:
return x->y

If the documentation is unclear or misleading, it should be corrected.

Dave Cuthbert
dacut at cadence dot com

[*] I've found that Andrew is generally correct about most everything he
posts.

 

I didn't even suggested he was wrong. obviously he was (and as you say
he is most of the time...)
I just wanted to raise the point. when you know it, you know it, but
when you don't you look in the doc (or ask comp.cad.cadence which is
sometimes a better and quicker way). I did the "flow" for finding
this out in the doc and found out it wasn't very clear to me. this
"flow" i was trying to describe, and see where the confusion came from.

this couldn't be clearer. when you see this, you understand 100% how ~>
works. I think in the doc it isn't that clear however. apparently
definition of atom or "atomic object" should be "anything but a list".

cheers,
stéphane

 

I meant right of course

 

Thanks andrew for the clarification.

Regards,
Suresh

 

the main difference is what happens if the object is a list
if some_list is a list of dbobjects then

some_list~>xyz builds a list of xyz extracted from each of the instances.

if some_list is a dpl, then some_list->xyz returns the value of
xyz from that dpl.

e.g.,

some_list = '(nil a 100 b 200 c 300)
some_list->b ;; evaluates to 200

some_list = (geGetEditCellView)~>instances
some_list~>name ;; returns a list something like ("I1" "I2" "I3" ....)

traditionally however, ~> was used to access dbobjects and -> was
used to represent SKILL's built in data types. I normally
use ~> with dbobjects such as
d_inst~>name to emphasis that d_inst is a dbobject. However,
not so many people agree with my usage.

hope this helps.

-jim

 

no! atoms are everyting other than lists with the exception of
nil, which is both an atom and a list.

A dpl is a list, not an atom.
A hash table is an atom not a list.
A symbol is an atom, not a list.

There is no such thing in SKILL as a SCALAR type. Perhaps
there a symantic difference, but the language does not
support such a difference.


You can use the function, atom, to tell whether an object
is an atom or not.

Remember you can also put and get properties from symbols

x.prop1 = 100
x.prop2 = 200
y='x

y->prop1 --> 100
y->prop2 --> 200

 

yes stéphane in most versions of LISP an atom is anything except
a list (with the possible exception of nil with is both).

Even if an object is an atom, it might still lead you to more
(hierarchical) information. examples being symbols, hash tables,
defstructs, class instances, dbobjects, windows, cdf objects and
many other types of objects.


-jim

 

Actually that's what I tend to do (when writing using C-like syntax, which I
don't do often...) - so I _would_ agree with your usage!

Andrew.

 

Just to make this thread complete for future reference as novice SKILL
programmer:

How would you write the -> and ~> operators when you don't use the
C-like syntax?

 

(getq obj prop) or (putpropq obj value prop)
(dbGetq obj prop) or (dbSetq obj value prop)

(first on each line is for retrieval, second for setting).

Note that this is not really the same as ~> because it is not operating on
lists - the equivalent function would be (getSGq or setSGq) but then again I
don't tend to use the implicit mapcar functionality...

Andrew.