G
Giuseppe
Guest
Hello,
what is the difference between -> and ~> operator??
Giuseppe
what is the difference between -> and ~> operator??
Giuseppe
G
Giuseppe
Guest
Thank you! Very clear. ;-)
Giuseppe
Giuseppe
S
Suresh Jeevanandam
Guest
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
operator on it for this to work.
Suresh
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
S
S.Badel
Guest
S.Badel wrote:
I didn't even suggested he was wrong. obviously he was
I meant right of course
J
Jim Newton
Guest
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
Giuseppe wrote:
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
Giuseppe wrote:
J
Jim Newton
Guest
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
J
Jim Newton
Guest
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
A
Andrew Beckett
Guest
On Mon, 14 Feb 2005 23:44:00 +0100, Jim Newton <jimka@rdrop.com> wrote:
don't do often...) - so I _would_ agree with your usage!
Andrew.
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.
S
Svenn Are Bjerkem
Guest
Andrew Beckett wrote:
programmer:
How would you write the -> and ~> operators when you don't use the
C-like syntax?
--
Svenn
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?
--
Svenn
A
Andrew Beckett
Guest
On Wed, 16 Feb 2005 08:46:40 +0100, Svenn Are Bjerkem <svenn.are@bjerkem.de>
wrote:
(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.
wrote:
(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.
A
Andrew Beckett
Guest
On 10 Feb 2005 06:36:32 -0800, scosmo@tiscalinet.it (Giuseppe) wrote:
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.
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 asa 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 implicitforeach(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.
A
Andrew Beckett
Guest
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.
On Fri, 11 Feb 2005 13:58:18 +0530, Suresh Jeevanandam
<sureshj@DELETETHISti.com> wrote:
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.
On Fri, 11 Feb 2005 13:58:18 +0530, Suresh Jeevanandam
<sureshj@DELETETHISti.com> wrote:
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
lstOfObjs=list(obj1 obj2 obj3 obj4)
lstOfObjs~>myprop
is like doing:
list(obj1~>myprop obj2~>myprop obj3~>myprop obj4~>myprop)
list(obj1->myprop obj2->myprop obj3->myprop obj4->myprop)
or put another way:
foreach(mapcar obj lstOfObjs obj~>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.
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.
Regards,
Suresh
S
S. Badel
Guest
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)
Arrow (->
Operator-------------------
The arrow (->
operator can be applied to disembodied property lists, defstructs, associationtables, 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)
D
David Cuthbert
Guest
S. Badel wrote:
(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.
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.
S
S.Badel
Guest
David Cuthbert wrote:
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.
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 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
S
Suresh Jeevanandam
Guest
Thanks andrew for the clarification.
Regards,
Suresh
Andrew Beckett wrote:
Regards,
Suresh
Andrew Beckett wrote:
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.
On Fri, 11 Feb 2005 13:58:18 +0530, Suresh Jeevanandam
sureshj@DELETETHISti.com> wrote:
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
lstOfObjs=list(obj1 obj2 obj3 obj4)
lstOfObjs~>myprop
is like doing:
list(obj1~>myprop obj2~>myprop obj3~>myprop obj4~>myprop)
list(obj1->myprop obj2->myprop obj3->myprop obj4->myprop)
or put another way:
foreach(mapcar obj lstOfObjs obj~>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.
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.
Regards,
Suresh