plain_fsm - for beginners and purists

Ulf Wiger <>
Thu Feb 12 16:30:20 CET 2004


On Thu, 12 Feb 2004 09:47:12 -0500, Shawn Pearce <> 
wrote:


> It would be nice if the code just didn't compile if you forgot the parse
> transform, rather than waiting until runtime to crash however. :)

I'm not sure this can be done... actually it could, if
I made it a local function instead:

idle(S) ->
    plain_fsm_receive(
       ...
    end).

Then we have to hope that the programmer hasn't actually
written a function plain_fsm_receive/1 for some
other purpose... ;-) We can minimize the risk by inventing an
unbelievably ugly name for the function...

Everyone with a strong opinion on the subject, please speak up.


> I thought a fun wasn't usable after a module was reloaded, because the
> reference to the code that the fun was using was directly to the
> a single version of the module (and not an external call)?
>
> Besides, can't a fun's magic name change between compiles, especially
> if I add another fun, so if it did use an external call to execute the
> fun in the new module, it might run the wrong fun?

I can't account for the algorithm used to generate fun names, but it
is relative to the enclosing function, so the only time you will break
a fun during code change is if you've inserted a fun definition ahead
of it in the same enclosing function... I think.


> Or:
>
> 	-keyword(plain_fsm_receive, my_app_receive).
>
> 	plain_fsm_receive
> 	...
> 	end.
>
> with the parse transform converting to my_app_receive, (rather than
> just receive) so another parse transform can kick in.  This is already
> possible with your current design, so perhaps that's really the best
> we have today...

Ok, then let's add

behaviour_info(keywords) ->
    [plain_fsm_receive].

And have the linter check that you're not redefining keywords
used by the behaviour you're using.  (:

/Uffe
-- 
Ulf Wiger, Senior System Architect
EAB/UPD/S

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.




More information about the erlang-questions mailing list