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

Rüdiger, if you want to encode FSMs, you don't want to worry about in-lining constants. You want a macro that helps you write down the ENTIRE FSM and then compiles to small, efficient code. Think back to your Formal Languages course. A regexp is some alphabet Sigma, States, Initial States, Final States, Transition table. So you might wish to start with 

(define-syntax (define-fsm stx)
  (syntax/parse stx 
    [(_ Alphabet States Initial Final Transitions) …]))

I am pretty sure that the question of in-lining constants won't even come up. It'll just happen. 

In general, I urge you to not to translate C ideas into Racket. Think bigger. 

[[Many years ago I had to rewrite a large chunk of code that a then-undergraduate/now-famous-professor had constructed as infrastructure for some AI course. The code had literally been translated from C to Scheme, with ref cells playing the role of pointers. Some functions looked like this 

 ;; [Box Integer] -> Void 
 (define (f result) .. .. (set-box! result e) (void)) 

Students soon complained that the Scheme code was an order of magnitude slower than the C code. With a day's worth of work, I rewrote it into a much more functional style and cut its run time in half and less. Then I started worrying about where the cost went in a Scheme program. It really makes no sense to copy C idioms in Scheme or Lisp or Racket. Compilers aren't built that way.]]

-- Matthias





On Mar 9, 2012, at 6:25 AM, Rüdiger Asche wrote:

> Hi there,
> 
> #1: My graduate thesis (in 1988) was an implementation of Scheme. I do feel reasonably comfortable with tail recursion, continuations, closures and the "basics," even the basic notion of hygienic macros (which Eugene Kohlbecker had just finished his doctorate on when I studied Scheme at IU). There are a number of things that have drastically evolved since then, though. I have taken up Racket again in February (see #2).
> 
> #2: I'm indeed in Embedded where every byte and every cycle counts, and since my pet project is to eventually run Scheme code on Embedded Controllers, implementation details ARE an issue - even on 32 bit machines some of which have to make do with as little as 256k Flash and 64k RAM. It's the luxury of academics to deal with the big picture; it's my job to get things to work out there in the world - it's as simple as that ;-)
> 
> The trigger for my question was an fsm I am working on now, along the lines of
> 
> (define (vendingmachine currentstate)
>  (let ((newstate
>     (case currentstate
>         [(VENDINGMACHINE_IDLE)
>              (if (CoinInserted)
>                  VENDINGMACHINE_INSERTED_COIN
>                  VENDINGMACHINE_IDLE
>              )
>         ]
>         [(VENDINGMACHINE_INSERTED_COIN)
>              ...
>         ]
>         [
>         ]
>         [
>         ]
>         [
>         ]
>     )
>    (vendingmachine newstate)  ; make sure this remains in tail recursive position
>  )
> )
> 
> ...
> 
> (vendingmachine VENDINGMACHINE_IDLE)
> 
> 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?
> 
> Not Thomas' remark about "defines being inlined most of the time" sounded interesting. Is it really like that? Under what circumstances, and can I control that behavior?
> 
> Thanks again!
> 
> 
> Quoting Neil Van Dyke <neil at neilvandyke.org>:
> 
>> First of all, sounds like you have a substandard C compiler, and that
>> you must be targeting a 4-bit microcontroller. :)
>> 
>> Regarding these micro-optimizations in Racket: if you are fairly new to
>> Racket (I don't know), my suggestion is to avoid trying to optimize
>> every word of allocation and every variable reference overhead, and
>> instead focus on learning the idiomatic language.  I suggest pretending
>> that variable references are negligible for now, and instead focus on
>> things like trying to make tail calls, and trying to avoid variable
>> mutations.
>> 
>> -- 
>> http://www.neilvandyke.org/
> 
> 
> 
> 
> ____________________
> Racket Users list:
> http://lists.racket-lang.org/users