This is a read-only archive of lispforum.com. The forum was locked to new users and posts and is preserved here as static HTML from a database snapshot taken on 2019-09-07.

get/set dilemma

3 posts · 4039 views

Hello boys/girls (there's any girl here?). I've a question. I've read here

http://axisofeval.blogspot.com/search?u ... results=23

a question about the today existence of CAR and CDR functions on new lisp dialects. This have bring to me a consideration on my dialect. I try to expose to you my dilemma.

My system define structures like packages, funtions, structures, types in an anonymous way. A type can be created in this manner:
(define types:2d-point (type nil :x :y))   --->   #<type |2d-point| (x y)>
and create an object of type types:type. Then
 (struct types:2d-point :x 0 :y 0) ---> #S(2d-point x 0 y 0) 
will make an object of type types:2d-point with X and Y set to 0. Ok? Good!! The type object have the name "2d-point" because is registered into the package TYPES. Technically TYPES is a package that contain symbols whose values is a named type.

In the following instruction, the type have no name, because is not registered into TYPES:
(struct (type nil :x :y) :x 0 :y 0) --->  #S(#16:00E49E88 x 0 y 0)
In few words, this permit to use unnamed packages, unnamed types and so on. Package definitions work in the same manner.

Ok ?? GOOOOD!!!

So ... reading that link, where the author say to use structures for CONSES .. make me thinking that CAR and CDR can be fields of a structure, and so name and nicknames of types or packages can be fields of a structure too.

Then if I wanna know the name of a type I probably wanna write something like this:
(get :type X) ---> types:my-type 
But, if "type" is a field defined by the user??
(define types:my-type (type nil :type :x :y))
(define x (struct types:my-type :type "XY" :x 0 :y 0))
 (get :type x)  --- ????
I wanna still have the possibility to get the type of x which is TYPES:MY-TYPE. Same problem on packages: the type of the object (types:package) or the value of the symbol "type" defined into the package?

The goal is to remove functions like
  • name-of
    nicknames-of
    imaginary-of
    real-of
    sign
    packages-of
    car
    cdr
    set-car
    set-cdr
    size-of
    type-of
and others, in favour of a generic Get/Set mechanism. This is a problem for me because TYPE is always a field .. even if you use "NAME" for the name of the package or a symbol "NAME".

How can I resolve this problem?


Thank you.

Re: get/set dilemma

Does your Lisp dialect have a Common-Lisp-style package system? If so, one solution would be to make the slot names symbols in some package rather than keywords.

If your dialect uses a module system based on bindings rather than one based on symbols, there's still a way: Instead of using symbols as slot identifiers, use first-class values and bind them in the appropriate name space. For example, say there are two modules, USER and SYSTEM, then I might do something like this (in pseudo-Lisp):
(in-module user)

;; Definitions
(define-slots !x !y !type)
(define point (type nil !type !x !y))

;; Example program
(define p (struct point !type "XY" !x 0 !y 0))
(println !x)                    ;=> #<SLOT-TAG !X>
(println (get !x p))            ;=> 0
(println (get !type p))         ;=> "XY"
(println (get system:!type p))  ;=> USER:POINT
(In the above piece of example code, the “bang” character (!) is mere convention, not special syntax.)

Re: get/set dilemma

Mmmm packages are more or less the same of CL. Have a name, nicknames, a use list. But symbols are all visible to the external world.

I've omitted a thing...symbols and packages are made at read time. This mean that if I read from command line something like "MATH:ACOS" without loading the math library, automatically make a MATH package with an ACOS symbol with NIL as value.

This may be a problem using symbols for slot definition because make a proliferation of objects. Also, a type object may have a super type (the first argument of TYPE).
(define types:3d-point (type types:2d-point :z))
And, actually, fields are accessed by name not by symbol reference. I can use strings instead.