Path: utzoo!attcan!uunet!husc6!purdue!umd5!umbc3!alex
From: alex@umbc3.UMD.EDU (Alex S. Crain)
Newsgroups: comp.lang.lisp
Subject: Re: query 'bout defstruct (Common LISP)
Keywords: defstruct, symbols, confusion
Message-ID: <982@umbc3.UMD.EDU>
Date: 14 May 88 05:28:51 GMT
References: <10834@cgl.ucsf.EDU> <5190@bcsaic.UUCP> <28800@yale-celray.yale.UUCP> <974@umbc3.UMD.EDU> <384@mancol.UUCP>
Reply-To: alex@umbc3.UMD.EDU (Alex S. Crain)
Organization: University of Maryland, Baltimore County
Lines: 68

In article <384@mancol.UUCP> jh@manhat.UUCP (John Hanley) writes:
>>The motivation behind the gensyms is to avoid a list or table structure.
>
>I submit that you probably don't have a clear enough idea of what you want
>your data structure to look like if you're using arguments like this.

	Well, depends on what "enough" is. The truth is, I'm not convinced that
the final version of this project will look much like it does now, and I want
alot of freedom to play with what I have, structure-wise. And that was my 
point.

	Symbols are certainly not an effecient way to build a data structure,
but they do have certain advantages, and (gensym) certainly has its purpose.
As this project progresses, I'm dealing with a progressively complex data
structure where each node may have a several links or more, built as an
n-ary tree structure with interconnected branches. Effeciencey and ellegance
would have me hashing structures as you suggest, but practicality has me 
using symbols because...

	The data structure is really several several structures overlayed
over one another. plists are gross, but they are flexable and fast in an 
interactive environment, which is where I play with my data. I can add or
delete a piece of information from a node without realoading the system, which
I would have to do if I was using structures. For example: My project 
a system for knowelege representation in an natural language environment. One
problem that I will eventaully have to deal with is how word classes affect
parsing action. But this isn't what the project is about (for now) so I wrote
a stupid parser and stuck the strings to the side of the symbols with scotch
tape (plist). When I had to rewrite the parser to take advantage of other
developments, I wrote another stupid parser, and moved the words around and
forgot about it.

	The other big plus was that the project is moving in a cycle that 
goes (1) decide what the data should look like (2) write a program to make the
data look like that (3) make the program work (4) play with the data and decide
what it should really look like (5) go to 2.

	This is fine until the data structure gets so mangled that it can't
be printed sensably, and then there is a problem with checking the output
of the program. symbols provide convienent tags into the data structure so that
I can test by predicting what the value of a symbol shold look like, and then
examining the symbol.

	And yes, I could build a hash table and that would work more 
effeciently (I do know how to use (make-hash-table)), but why? This program,
like alot of what I've been doing lately, will never go beyond the research
stage; ie: it only needs to work. Building what amounts to a customized symbol
table gains me nothing except effeciency that I don't need and another system
to maintain. Besides, If it ever did become desireable, moving to a more 
effecient handeling of graph nodes later would not be difficult, and would
almost certainly be simpler then building it now and fixing it every time
it breaks because of another change.

	My point was (and is) that symbols have ther purpose in life, just
like hash tables and structures, and by writing them off as gross and 
ineffecient, you cut off your nose to spite your face.

	Sort of like goto's :-).


>
>             --John Hanley
>              System Programmer, Manhattan College
>              ..!cmcl2.nyu.edu!manhat!jh  or  hanley@nyu.edu   (CMCL2<=>NYU.EDU)
-- 
					:alex.

nerwin!alex@umbc3.umd.edu
alex@umbc3.umd.edu