Re: memory usage in cmucl


josephoswaldgg@xxxxxxxxxxx wrote:
goose wrote:

<snipped>

The more "Lispy" approach from my point of view would be to take an
s-expression based "language for state machines" and using macros to
transform that language into Lisp code to implement it. This
transformation would typically be either an interpreter or a compiler,
and the power of Lisp makes the compiler achievable.


Yup; that is the intended aim in the end (can't have spurious
defconstants scattered throughout the program).

My first few attempts failed. I then made this attempt (the ugly one)
hoping that I'd be able to wrap it up later with a let* or similar.

The general way a state machine gets expressed *might* be something
like


*might* ? How do you normally do it?

(def-state-machine my-input-parser
:state-variables (input-char (line-char-count 0) result-line)
:initial-state start-state
:termination-state end-state
:return-value result-line
(start-state :action (setf input-char (read-char))
:transition
(cond
((digit-char-p input-char) store-digit)
(t start-digit)))
(store-digit :action
(setf line-char-count (+ (* 10 line-char-count) (digit-char-p
input-char))
:transition
...)))

I.e. a state machine consists of

1) state variables

Sure

2) state nodes, each of which has
- an action function which gets called when the state is "entered"

Not really needed; the most I'd use it for is diagnostics (which is why
I
wrote a macro to define the state).

- a "transition function" which is called and returns the next node
in the state machine to be executed.

Really, the logic of a single state (or body). "Transition" implies
a state change; very often you may remain in the same state.

3) an initial state, which are values for the state variables and an
initial node

Yup

4) a final state (or states?)

Only one. In a state machine having a number of different
end states makes as much sense as having a number of
different start states.

which, when reached, indicate the state
machine has finished executing. (It might make sense to have a
convention that the node represented by NIL is always a final node...)

I did that, hence only a single end state.

5) a "return value" which, when the final state is reached, represents
the summary of the state variables which is of interest

sure.


The macro "def-state-machine" would create a data structure containing
those nodes, where the nodes probably contain *compiled* Lisp
representations of the action and transition functions, encapsulating
the state variables, and Lisp function called to create the final
return value, and define a corresponding class.

I will have a bash at something like that, and repost.


There would almost be

(setf *my-parser* (make-instance 'my-input-parser))

Then, there would be a method

(run-state-machine *my-parser*)
;; runs, gathers input 5abcde
--> "abcde"


I would change this slightly to allow the caller to step
the machine one state at a time (for all the reasons I mentioned
in my previous post), but other than that, I initially did something
similar using a class to hold the entire machine; I always got
lost when trying to reference states that were not yet declared
so I decided to use a defconstant for each state.

I will maybe make another attempt and repost this weekend
if I get the time.

<snipped>

I was hesitant to discuss this in such detail, because I was hoping
some more experienced Lisper would point you to a state machine package
which has a fully designed solution for this problem space, instead of
some 15-minute design that I whipped up for Usenet.

Unfortunately using a prepackaged solution may solve the immediate
problem (implementing my protocol), it defeats the purpose entirely
(which is to explore and experiment this new programming language
I found:-)

anyway, thanks for your comments and tips, I'll make an attempt
to keep all of it in mind (saved to a disk, actually) for my next
iteration
of this.

goose
(btw: I still do not know why cmucl is giving me memory leaks on
the original code. Any ideas in that direction about how lisp code
can actually leak memory would be helpful)

.

Relevant Pages

  • Re: memory usage in cmucl
    ... I would probably find a Common Lisp library ... had a problem that really needed elaborate state machine ... in which case your transition function could return the ...
    (comp.lang.lisp)
  • Re: memory usage in cmucl
    ... I would probably find a Common Lisp library ... My design intent was to separate the "work getting done" from the logic ... In a state machine having a number of different ... (make-state stateN (...)) ...
    (comp.lang.lisp)
  • Re: A Proper Lexer
    ... Common Lisp. ... e.g. if you can design it so that the little language has a space ... experimental packrat parser (which describes the construction of tokens and ... If you design it with a state machine macro - code executed ...
    (comp.lang.lisp)
  • Re: A Proper Lexer
    ... Common Lisp. ... e.g. if you can design it so that the little language has a space ... If you design it with a state machine macro - code executed ... get away with fully-backtracking parsers and a packrat parser with no ...
    (comp.lang.lisp)
  • Re: C++ sucks for games
    ... have been shown Lisp code that is shorter than your C++ code. ... the Lisp syntax here scales very well ... That a language which you presumably rarely, ...
    (comp.lang.lisp)