[racket] eginner's question on elementary textual replacement...

From: Rüdiger Asche (rac at ruediger-asche.de)
Date: Fri Mar 9 11:00:23 EST 2012

True, there is no need for any particular way of representing the states as 
long as there is some way  to test two things for equality. However, unless 
the compiler can be told to disregard the internal representation of the 
symbol, it won't eat up lookup time but representation space - ie if I did 
the comparison on quoted identifiers such as 'vendingmachine-idle or 
"vendingmachine-idle," I don't see how the symbols themselves (the things 
that the constant-time pointers you refer to point to) wouldn't need to be 
stored literally somewhere in memory (might easily add up to a couple of 
hundred bytes in memory that are of no use whatsoever). Now possibly there 
is some way to tell the compiler to discard the objects themselves and only 
party on the references, but that would be sort of a kludge (why have a 
pointer if it points to nothing? What's the garbage collector to think about 
that?) - the most efficient and "natural" way (at least for a C programmer; 
see my responses to Matthias for that) to do it at runtime would be to 
compare against integers, but the readability of code would suffer 
tremendously if I had integers instead of expressive symbols in my code, so 
I was looking for some way to provide a trivial preprocessor time mapping 
between symbols and integers. Interesting that apparently, there is nothing 
like that, so I wonder what a more natural or Schemish way there wsould be 
to tackle such an issue...

Very meaningful discussion, by the way, thanks a lot!

> (define (vendingmachine currentstate)
>  (let ((newstate
>     (case currentstate
>         [(VENDINGMACHINE_IDLE)
>              (if (CoinInserted)
>                  VENDINGMACHINE_INSERTED_COIN
>                  VENDINGMACHINE_IDLE
>              )
>         ]
>         [(VENDINGMACHINE_INSERTED_COIN)
>              ...
> ...
>
> where every of the VENDINGMACHINE_xxx identifiers is very simply a 
> readable symbolic identifier for a disjoint constant. I have a hard time 
> believing that in reasonably complex fsms, it shouldn't impose a severe 
> performance penalty to look up a constant every time it is used?

Why not just use symbols for these, without worrying about what they "stand 
for"?  If you've implemented a Scheme system, you know about interned 
symbols: the symbol-table lookup should happen at compile-time (right?), so 
you're left with a constant-time pointer comparison at run-time.

Disclaimer: I've implemented only "toy"-scale Schemes myself.


Stephen Bloch
sbloch at adelphi.edu


Posted on the users mailing list.