[eeps] allow external function as literals
Björn-Egil Dahlberg
egil@REDACTED
Fri Oct 3 12:32:50 CEST 2014
I'm very well aware of this and I totally agree that you cannot do this
for all "constants".
I thought it obvious and didn't mention that constants has to be side
effect free.
On 2014-10-03 04:32, Richard A. O'Keefe wrote:
> On 3/10/2014, at 4:03 AM, Björn-Egil Dahlberg wrote:
>> Is there any other potential literals that are needed. I don't think so, perhaps only solve this for fun exports and not the general case .. If it needs solving that is.
> Just because a value *could* be explicitly written as
> a literal doesn't mean it is *easy* to do so.
>
> Don't make the mistake of thinking that "is a literal" and
> "is evaluated only once" are the same. They aren't.
> Suppose you want to have a list of references that is
> going to be requested often.
>
> You cannot write a reference as a literal at all.
> You *can* fake it by doing
>
> B = term_to_binary([make_ref() || I <- lists:seq(1, 100)])
>
> then pasting that into the skeleton
>
> refs() -> binary_to_term(
> % paste here
> ).
>
> But it would be better if you could write
>
> -once.
> refs() ->
> [make_ref() || I <- lists:seq(1, 100)].
>
> I note that if something is a literal in Erlang I can use
> it in a pattern. This is not true of fun mod:name/arity.
> With the patch we are discussing to make these things that
> can be stored at load time, they still are not *LITERALS*.
>
> Think of the possibilities of tree-structured sets and
> dictionaries; you *can* break encapsulation and write those
> as explicit ground terms, but you would be mad to do so.
> Personally, I've wanted to do that several times.
>
>
>
>
>
>
More information about the eeps
mailing list