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
sbl...@adelphi.edu

____________________
 Racket Users list:
 http://lists.racket-lang.org/users

Reply via email to