From: Ari Johnson
Subject: Re: Mapping tables
Date: 
Message-ID: <aJSpc.164804$f_5.78472@lakeread01>
Dave Roberts wrote:
> I was editing a bit of my resolver library today and decided to finally deal
> with something I have been skirting for a while. Simply, what is the best
> way to create a nice mapping table from integers<->symbols. In my case, I
> want to map from symbols representing DNS types (A, MX, TXT, etc.) to the
> corresponding type codes. I need to do this both directions, from symbols
> to codes when creating a query, and from codes back to symbols when
> decoding the response. I have tried this a couple ways before this, but
> they always felt kludgy.
> 
> First attempt was simple a-lists. Write two functions to use ASSOC and
> RASSOC and we're in business. Nicely data driven.
> 
> But then I started to think speed. A-lists are not fast when the size is
> large.
> 
> So, then I went to a version using two functions with hard-coded CASE forms.
> Works great, but now I have to remember to add mappings into two places.
> 
> Then... I started to think that this is an ideal place to use macros. Why
> not give myself a nice syntax like creating an a-list, but then transform
> that into a case statement. Here's what I came up with. It feels kludgy and
> probably has all sorts of other macrology issues.
> 
> So, please tell me if you would do this differently. If so, how? If you'd do
> it like this, how does my code look?
> 
<snipped-code />

I don't see any problem with it per se, although I wonder how fast it 
really needs to be.  As I see it, alists exist for this exact purpose. 
But, if it has to be fast, your code is fine since, as I see it, macros 
are purpose-built to let you write short, elegant code instead of big 
kludges, letting the macro take care of kludging it up for you.
From: Dave Roberts
Subject: Re: Mapping tables
Date: 
Message-ID: <G4Vpc.63820$iF6.5607396@attbi_s02>
Ari Johnson wrote:

> I don't see any problem with it per se, although I wonder how fast it
> really needs to be.  As I see it, alists exist for this exact purpose.
> But, if it has to be fast, your code is fine since, as I see it, macros
> are purpose-built to let you write short, elegant code instead of big
> kludges, letting the macro take care of kludging it up for you.

Truthfully, it doesn't have to be fast. The speed of a lookup is really
bound entirely by the network interaction. The decoding is basically noise
and this part of the decoding is less than noise. That said, it's mostly a
general question on Lisp style and idiom. I'm mostly just curious how
others would solve the problem; the answers help me learn by pointing out
solutions that I didn't think of.

-- 
Dave Roberts, ·············@re-move.droberts.com
Slowly but surely, the programming world is finding Lisp...
http://www.findinglisp.com/blog