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 <n...@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
____________________
Racket Users list:
http://lists.racket-lang.org/users
