Re: [efene] Status of not yet mentioned/published (Erlang) features
- From:
- Uwe Dauernheim
- Date:
- 2010-09-28 @ 12:19
On 28.09.2010, at 02:01, Mariano Guerra wrote:
> On Mon, Sep 27, 2010 at 12:28 PM, Uwe Dauernheim <uwe@dauernheim.net> wrote:
>> Hej,
>>
>> I am through with the mailing-list now (ok, was not much :-)) and
discovered a bunch of open questions.
>>
>> @Mariano Do you think it is a good idea to have list of not yet covered
Erlang features and describe what’s their status? (Maybe they are already
and I haven’t try them). I will give it a try and enumerate what I think
of:
>>
>> * Macros
>> * Header files (especially -include, -include_lib, -import)
>> * Bitstring operations(?)
>>
>> /Uwe
>
> macros are supported through metaprogramming, imagine you want to use
> an expression that is slow to calculate and use a macro to insert it
> in the places where it's used, with metaprogramming you could do:
>
> mariano@ganesha:~$ cat meta.ifn
>
> @public
> run = fn ()
> List = $[lists.seq(1000, 1020)]
> fio.println(List)
> mariano@ganesha:~$ fnc -t erl meta.ifn
> -module(meta).
>
> -export([run/0]).
>
> run() ->
> List = [1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007,
> 1008, 1009, 1010, 1011, 1012, 1013, 1014, 1015, 1016,
> 1017, 1018, 1019, 1020],
> fio:println(List).
> mariano@ganesha:~$ fnc meta.ifn
> Compiling meta.ifn
> mariano@ganesha:~$ fnc -r meta run
> [1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, 1008, 1009, 1010,
> 1011, 1012, 1013, 1014, 1015, 1016, 1017, 1018, 1019, 1020]
>
> as you can see in the erlang version the list is generated at compile
> time and inserted in the program. of course you can make more complex
> things and insert the result there, you can even insert arbitrary code
> in place at compile time.
>
> about the header files yes, I have to add them. I should think which
> ones are necessary and how to add them.
>
> I will start a page in the documentation with a list of features and its status.
>
> bitstring operations are already supported, you can look in the test
> folder to look for implemented features and its erlang counterpart.
>
> http://github.com/marianoguerra/efene/blob/master/test/literals.erl#L115
> http://github.com/marianoguerra/efene/tree/master/test
To bitstrings: Thanks for the bitstring example, I rushed a bit too fast
over that.
To macros: Ok, I get the idea about the meta programming for macro and it
works. However, when comparing to a random current Erlang code base, I/we
use to declare the macros outside of the funs, mostly even outside of the
module file (I am relating here to the hrl header files). With that it is
very easy to gain different global configuration sets without having to
change all files that use the macro; like a -define(timeout, 1000). and
then use it all over the place. So not for performance reasons but rather
extraction.
I am not experienced enough to decide if it is possible to gain something
similar, and how the corresponding syntax should then look like (maybe a
global attribute like „@@define(X, Y) ?) and then use it like other macro
variables ($module, $line, ...) .
To the header files: In fact, I never really understood why there is a
differentiation between erl and hrl from a programmatic standpoint. erl
files can be included as well as hrl files and hrl files can include
natural Erlang syntax. The only difference is that get included as they
are, so they don’t need a -module etc. definition. I believe Efene doesn’t
need a separation in header and body/code files like fn/hfn, efn/hefn,
ifn/hifn or similar. When the parser detects an include, the file gets
fetched and appended. If a wrong pathname is given by the developer, the
parser can’t really see if this file is meant to be as a header or code
file (the syntax should look the same besides @public). Resulting in: bad
luck.
I am just not sure how the syntax for them could look like. I believe
includes should not be "@@include(X)“ as the „@" aims to correspond to
„@nnotation“ and includes are not really annotations like author, type,
spec. I also believe it could not be the Python syntax of „import X“ for
Ifene as import in Python is more like the import in Erlang and not the
include. And for Efene I also have no real clue as the JS world didn’t
really figure out a unified solution yet, leaving left Rhino with its
„load(X)“ or C with its „#include X“. It feels like I would go on both
sides for a simple „include X“, keeping its Erlang nature and not
interfering with import, either in Erlang nor Python nor C.
What do you think?