librelist archives

« back to archive

Status of not yet mentioned/published (Erlang) features

Status of not yet mentioned/published (Erlang) features

From:
Uwe Dauernheim
Date:
2010-09-27 @ 15:28
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

Re: [efene] Status of not yet mentioned/published (Erlang) features

From:
Mariano Guerra
Date:
2010-09-28 @ 00:01
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

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?