Discussion:
Naming suggestions
Antoniotti Marco
2016-02-04 18:03:33 UTC
Permalink
Dear all,

in the quest for RESTHBDB) RE-doing Stuff That Has Been Done Before) I am trying to come up with a name for a referencing/dereferencing operator.

Think of something like

(<name-of-reference-operator> #2A((1 0) (0 1)) 0 0) ==> 1

of

(<name-of-reference-operator> #H((foo . bar) (we . 42)) ‘foo) ==> BAR ; I am cheating. #H(..) is a hash table.

SETF methods will be defined as expected.

Now. What could be a good name? I have the following list.

REF
REF$
[]
[[]]
AT
@
GETAT

What do you think? (Full disclosure: I usually refrain from taking up non alphabetic names)

Cheers

MA
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://cdac.lakecomoschool.org

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.
Kenneth Tilton
2016-02-04 18:29:22 UTC
Permalink
I like AT.

I would be concerned by (setf (getat ....) ...)

My thoughts were GREF and XREF, and why we are not using a case-sensitive
Lisp.


hth, hk

On Thu, Feb 4, 2016 at 1:03 PM, Antoniotti Marco <
Post by Antoniotti Marco
Dear all,
in the quest for RESTHBDB) RE-doing Stuff That Has Been Done Before) I am
trying to come up with a name for a referencing/dereferencing operator.
Think of something like
(<name-of-reference-operator> #2A((1 0) (0 1)) 0 0) ==> 1
of
(<name-of-reference-operator> #H((foo . bar) (we . 42)) ‘foo) ==> BAR ; I
am cheating. #H(..) is a hash table.
SETF methods will be defined as expected.
Now. What could be a good name? I have the following list.
REF
REF$
[]
[[]]
AT
@
GETAT
What do you think? (Full disclosure: I usually refrain from taking up non alphabetic names)
Cheers
MA
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
Please check: http://cdac.lakecomoschool.org
Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.
--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

***@tiltontec.com
http://tiltontec.com
@tiltonsalgebra

646-269-1077

"In a class by itself." *-Macworld*
Antoni Grzymała
2016-02-04 18:36:52 UTC
Permalink
Post by Kenneth Tilton
I like AT.
I second AT, it's nicely concise and communicative.
Giovanni Gigante
2016-02-04 19:03:02 UTC
Permalink
I think I like REF because it's also possible to pretend that it's just
RE (for REference) followed by a mysterious F, just like SETF.

Else, FREF, for similar mystagogic reasons, being sort of a generalized
form of things like AREF and SVREF.

On a more serious note: AT is good because it's concise, although
slightly vague in semantics maybe.


gg
Post by Antoniotti Marco
Dear all,
in the quest for RESTHBDB) RE-doing Stuff That Has Been Done Before) I
am trying to come up with a name for a referencing/dereferencing operator.
Think of something like
(<name-of-reference-operator> #2A((1 0) (0 1)) 0 0) ==> 1
of
(<name-of-reference-operator> #H((foo . bar) (we . 42)) ‘foo) ==> BAR
; I am cheating. #H(..) is a hash table.
SETF methods will be defined as expected.
Now. What could be a good name? I have the following list.
REF
REF$
[]
[[]]
AT
@
GETAT
What do you think? (Full disclosure: I usually refrain from taking up non alphabetic names)
Cheers
MA
--
Marco Antoniotti, Associate Professortel.+39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
Please check: http://cdac.lakecomoschool.org
Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.
Steve Haflich
2016-02-04 19:25:32 UTC
Permalink
<silly_question>
Does it work for plists? For alists?
</silly_question>

Can the user write methods to add his own structures/classes/constructs to
the set understood by REF?

More seriously, this function seems to me to be an over generalization,
distorting CL style. Built into the numerous built-in ways of supporting
data in CL are assumptions about the efficiency and scaling of the various
kinds. Although efficiency might not matter for particular low-bandwidth
operations, in other places it will certainly matter. That's obvious. But
even more important is that use of an over-generalized reference operator
makes the code harder to read and understand. If I see an aref, I know I'm
looking at an array, understand something about the expected performance,
and know what to look for elsewhere in a huge module to examine where this
array is constructed and modified.

For me, traditional CL operators have a nice, time-tested balance between
generality and specificity.
Antoniotti Marco
2016-02-04 20:05:34 UTC
Permalink
On Feb 4, 2016, at 11:25 , Steve Haflich <***@gmail.com<mailto:***@gmail.com>> wrote:

<silly_question>
Does it work for plists? For alists?
</silly_question>


Yes it does because you are wrapping the plists and the alist.

Sorry for the pointy response :) But I had anticipated the question and yes, I presume that lists and plists will be wrapped as in

(<reference-operator> (plist <your plist>) 'indicator)

Otherwise you are getting into nasty syntax with intermingling of indexing and other parameters to discriminate the “view” of the data. In other words I want this signature

(function (object index1 &rest more indexes) (values t boolean))

with the caveat that an array could have a index1 of NIL to accommodate
(aref (make-array () :initial-element 42)).

Can the user write methods to add his own structures/classes/constructs to the set understood by REF?

More seriously, this function seems to me to be an over generalization, distorting CL style. Built into the numerous built-in ways of supporting data in CL are assumptions about the efficiency and scaling of the various kinds. Although efficiency might not matter for particular low-bandwidth operations, in other places it will certainly matter. That's obvious. But even more important is that use of an over-generalized reference operator makes the code harder to read and understand. If I see an aref, I know I'm looking at an array, understand something about the expected performance, and know what to look for elsewhere in a huge module to examine where this array is constructed and modified.

For me, traditional CL operators have a nice, time-tested balance between generality and specificity.

This are all very valid points, but they are not the issue :) I have not given any context, but the reference operator will not be a CL-level operator. I am re-doing stuff in a DSL built upon CL, where all the CL operators will be usable, but where the overall goal is to offer other users what they may be used to.

Cheers
—
MA
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://cdac.lakecomoschool.org

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.
Faré
2016-02-04 22:49:08 UTC
Permalink
For the record, uiop has a general (but not extensible) accessor
called access-at.
lisp-interface-library has an extensible interface function lookup —
and yes, it works both on alist and on plist (if you supply an
appropriate interface object).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The shipwreck survivor's law: after a catastrophe, only the few survivors
erect votive shrines to thank deities for having saved them. The many
casualties don't erect anti-shrines to spit their contempt at the same
deities that failed to save them.
Post by Steve Haflich
<silly_question>
Does it work for plists? For alists?
</silly_question>
Can the user write methods to add his own structures/classes/constructs to
the set understood by REF?
More seriously, this function seems to me to be an over generalization,
distorting CL style. Built into the numerous built-in ways of supporting
data in CL are assumptions about the efficiency and scaling of the various
kinds. Although efficiency might not matter for particular low-bandwidth
operations, in other places it will certainly matter. That's obvious. But
even more important is that use of an over-generalized reference operator
makes the code harder to read and understand. If I see an aref, I know I'm
looking at an array, understand something about the expected performance,
and know what to look for elsewhere in a huge module to examine where this
array is constructed and modified.
For me, traditional CL operators have a nice, time-tested balance between
generality and specificity.
Paul Tarvydas
2016-02-04 20:30:31 UTC
Permalink
Actually, I see this as a dereference operator, not a reference operator.

In C, the reference operator is &, and dereference is * ...

pt
Antoniotti Marco
2016-02-04 22:00:16 UTC
Permalink
Good point.

Maybe “indexing operator" is a better characterization.

Marco
Post by Paul Tarvydas
Actually, I see this as a dereference operator, not a reference operator.
In C, the reference operator is &, and dereference is * ...
pt
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://cdac.lakecomoschool.org

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me f
Daniel Herring
2016-02-05 00:58:39 UTC
Permalink
Post by Antoniotti Marco
I am trying to come up with a name for a referencing/dereferencing
operator.
There are a bunch of names for such things: reference, address, pointer,
index, iterator, register, mark, tag, location, ID, name, alias, link,
key, position, slot, hole, stash, ...

Each of these has different semantic traditions. Without context, it is
hard to tell which evokes the "right" connotation.
Post by Antoniotti Marco
Think of something like
(<name-of-reference-operator> #2A((1 0) (0 1)) 0 0) ==> 1
or
(<name-of-reference-operator> #H((foo . bar) (we . 42)) ‘foo) ==> BAR
These example indicate names like "key" or "lookup". GET, FIND, SEARCH,
... are clearly taken.
Post by Antoniotti Marco
 I am re-doing stuff in a DSL built upon CL ... where the overall goal is
to offer other users what they may be used to.
Are these users coming from CL or another language? (Changes what they
may be used to.) Do they already have lingo for this concept?
Post by Antoniotti Marco
Maybe “indexing operator" is a better characterization.
The abbreviation "indop" is short, uncommon (no collisions or baggage),
pronouncable, and mnemonic. From a quick search, Indonesians may be the
only ones facing any level of potential confusion.


- Daniel
Vsevolod Dyomkin
2016-02-05 07:35:50 UTC
Permalink
In rutilsx I have called generic access operator ? - see here:
https://github.com/vseloved/rutils/blob/master/contrib/generic.lisp
It allows the accessor code to stand up a bit, which I consider a good
property. It is also chainable.

Here's an example usage (totals, weights and timestamps here are
hash-tables of hash-tables):

(defmethod update1 ((model avg-perceptron) f class val)
(with-slots (step timestamps weights totals) model
(incf (? totals class f) (* (- step (? timestamps class f))
(? weights class f)))
(incf (? weights class f) val)
(setf (? timestamps class f) step)))

AT also seems a decent choice

---
Vsevolod Dyomkin
+38-096-111-41-56
skype, twitter: vseloved

On Thu, Feb 4, 2016 at 8:03 PM, Antoniotti Marco <
Post by Antoniotti Marco
Dear all,
in the quest for RESTHBDB) RE-doing Stuff That Has Been Done Before) I am
trying to come up with a name for a referencing/dereferencing operator.
Think of something like
(<name-of-reference-operator> #2A((1 0) (0 1)) 0 0) ==> 1
of
(<name-of-reference-operator> #H((foo . bar) (we . 42)) ‘foo) ==> BAR ; I
am cheating. #H(..) is a hash table.
SETF methods will be defined as expected.
Now. What could be a good name? I have the following list.
REF
REF$
[]
[[]]
AT
@
GETAT
What do you think? (Full disclosure: I usually refrain from taking up non alphabetic names)
Cheers
MA
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
Please check: http://cdac.lakecomoschool.org
Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.
Alessio Stalla
2016-02-05 08:38:05 UTC
Permalink
Post by Vsevolod Dyomkin
https://github.com/vseloved/rutils/blob/master/contrib/generic.lisp
It allows the accessor code to stand up a bit, which I consider a good
property. It is also chainable.
Here's an example usage (totals, weights and timestamps here are
(defmethod update1 ((model avg-perceptron) f class val)
(with-slots (step timestamps weights totals) model
(incf (? totals class f) (* (- step (? timestamps class f))
(? weights class f)))
(incf (? weights class f) val)
(setf (? timestamps class f) step)))
AT also seems a decent choice
---
Vsevolod Dyomkin
+38-096-111-41-56
skype, twitter: vseloved
On Thu, Feb 4, 2016 at 8:03 PM, Antoniotti Marco <
Post by Antoniotti Marco
Dear all,
in the quest for RESTHBDB) RE-doing Stuff That Has Been Done Before) I am
trying to come up with a name for a referencing/dereferencing operator.
Think of something like
(<name-of-reference-operator> #2A((1 0) (0 1)) 0 0) ==> 1
of
(<name-of-reference-operator> #H((foo . bar) (we . 42)) ‘foo) ==> BAR ;
I am cheating. #H(..) is a hash table.
SETF methods will be defined as expected.
Now. What could be a good name? I have the following list.
REF
REF$
[]
[[]]
AT
@
GETAT
What do you think? (Full disclosure: I usually refrain from taking up non
alphabetic names)
Cheers
MA
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
Please check: http://cdac.lakecomoschool.org
Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.
Loading...