Yes Richard I remember most of this from the bad old days. :-)<br><br>What I was getting at was that there is no really no way to return a true function pointer in the way that Scheme or CL can do. This is not a Core problem but an Erlang implementation property. Even if doing<br>
<br>let MyCons = 'cons'/2 in apply MyCons(A, B)<br><br>is legal in Core as is generally using name/arity as data then unless these are optimised away as you mentioned then a later pass in the compiler, v3_kernel, actually converts them to a fun. In the Erlang implementation you cannot directly reference functions as data.<br>
<br>I personally think that it was a Good Thing that name/arity function names were kept in Core as it is a (mis)feature of Erlang and trying to hide this would have led to strangeness. That is why I have kept in the distinction in LFE and may even make it more noticeable. I am not yet decided either way.<br>
<br>Anyway letrec in LFE maps directly to letrec in Core, which works on name/arity function names, so the following LFE code is perfectly legal and works as expected:<br><br> (letrec ((f (lambda (x) (+ x n)))<br> (f (lambda (x y) (+ x (+ y n)))))<br>
(list (f n) (f n 10)))<br><br>Though it might be hard explaining to people that it is legal. :-) At least until they see it as Erlang and not as lisp. I don't really want to try and hide properties of the underlying implementation, especially when you can't really avoid seeing them. I mean I can define functions with the same name with different arities so I will never be able to refer to a function by just its name.<br>
<br>The Core Erlang spec, together with the record definitions, were a great help in generating code. That together with writing Erlang code and seeing what it resulted in.<br><br>Robert<br><br><div><span class="gmail_quote">On 02/03/2008, <b class="gmail_sendername">Richard Carlsson</b> <<a href="mailto:richardc@it.uu.se">richardc@it.uu.se</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Robert Virding wrote:<br> > Function bindings<br> > -----------------<br> ><br> > Core Erlang (and Erlang and the BEAM) separate variable and function<br> > bindings. A function binding has a name and an arity, this is a result<br>
> of allowing different functions to have the same name but different<br> > number of arguments. Also there is no concept of a function reference<br> > built into the Core and BEAM. It is therefore impossible to get a<br>
> reference to a function and pass it around, creating a fun which calls<br> > this function is not the same thing. So code like:<br> ><br> > In CL: (funcall #'cons a b)<br> > In Scheme: (let ((my-cons cons)) (my-cons a b))<br>
><br> > CANNOT work in Erlang.<br> <br> I think you can relax, Robert. This is not a problem.<br> <br> In plain Erlang, you'd write<br> <br> MyCons = fun cons/2,<br> MyCons(A,B)<br> <br> In Core Erlang, you write it like this:<br>
<br> let MyCons = 'cons'/2 in apply MyCons(A, B)<br> <br> Neither of these things mean that you'll necessarily get another<br> closure that will delegate the call - that's an old implementation<br> detail, which is not universally valid anymore. (E.g., with inlining<br>
enabled, this will reduce to a direct call "cons(A, B)".) And in<br> particular, there is just a single variable namespace.<br> <br> You're right that Core Erlang has no special notation ("fun f/N") for<br>
referring to a function (as opposed to defining it) - that's because the<br> keyword "fun" is not needed. Core Erlang has two flavours of variables:<br> normal Erlang-style variables, and 'atom'/integer function names. (We<br>
could actually have used only the first form, but then the Core Erlang<br> code would be harder to understand, and the export section would have to<br> look something like "export [ F17 as 'foo'/2, F32 as 'bar'/1, ... ]".)<br>
You can only define function-name variables in letrec-expressions, not<br> in let-expressions, but this is no limitation in general, since you can<br> easily bind a plain variable to a function-name variable, as above.<br>
<br> The main point here is: when you see some expression "'f'/3" in Core<br> Erlang or "fun f/3" in Erlang, think of it as just a name, a variable.<br> Forget about how "fun f/3" was originally implemented. This is one of<br>
the big things about Core Erlang: except for when you need to create<br> names of exported functions, that will be visible outside the module,<br> a variable is just a reference to some value, functional or not, and<br> it does not matter whether it was defined in a letrec or a let. This<br>
makes it much easier to do transformations like inlining on the Core<br> language level.<br> <br> /Richard<br> <br> PS. I know that it's not easy to grok the full consequences of the Core<br> Erlang specification; one has to sort of clear one's mind and start from<br>
scratch - if the spec doesn't prohibit something, then it should just<br> work (assuming that the compiler doesn't have a bug or is incomplete).<br> <br> [<a href="http://www.it.uu.se/research/group/hipe/cerl/doc/core_erlang-1.0.3.pdf">http://www.it.uu.se/research/group/hipe/cerl/doc/core_erlang-1.0.3.pdf</a>]<br>
<br> If you need human assistance to interpret some detail, just mail me.<br> <br> </blockquote></div><br>