<div dir="ltr">It seems like there are two separate threads here: one is about defining recursive functions in the shell; and the other is about defining local (recursive) functions in a module.<br><br>The first case has been reasonably covered in how you create a fun with a reference to itself so it can call itself recursively.<br>
<br>In the second case I must agree with Richard, there is no *need* to have local (to a function) functions, you can just use normal top-level functions. They *are * more efficient than funs. I have found, however, that I sometimes use funs as local functions when I want to stress that these are local functions. Especially after a bout of LFE hacking which has them.<br>
<br>However, if it was really desired it would be possible to add them, of course you would need both the recursive and non-recursive options. It would be a bit of a contrived expression as it would not, *could not*, return anything sensible. I would not like to add a scoping let type construction as we don't have having scoping anywhere else. Well except in funs and comprehensions where the scoping is a bit off actually. The visibility rules for the defined functions would be a bit hairy, very hairy really, but the best would be to make them the same as for variables, which are very hairy.<br>
<br>I have no intention of adding an EEP!<br><br>I don't like the idea of Self.<br><br>A rather humourous note is local functions in Core erlang. In Core yo have local functions, but only the mutually recursive type. These were originally added to implement comprehensions so only the recursive kind were needed.<br>
<br>A solution would be do what I used to threaten Bjarne with: do an E2 and get it right. What ever right is.<br><br>Robert<br><br></div>