librelist archives

« back to archive

A few newbie questions

A few newbie questions

From:
Oren Ben-Kiki
Date:
2012-11-05 @ 12:49
I'm toying with Erlang and I have in my past some experience with
Prolog-like syntax, enough to know that while it works, "it isn't optimal"
:-) So I'm giving Efene a look. I like the fact it is "just an alternative
syntax" and not a "whole new language", and that there's rebar integration.

I looked over the documentation and there are a few questions I didn't see
a clear answer to. Since Efene is basically an alternative syntax, this
automatically raises the question of "what is the Efene equivalent to the
Erlang construct X". A "cheat table" in the documentation would be very
useful... but anyway, here are the questions (and apologies if I just
somehow missed the answer in the documentation):

   - What is the proper way to document Efene source code? That is, should
   one use the Edoc's @doc comments etc.? And would that "just work" with
   "rebar doc"?

   - What is the way to have an Efene module specify
   "-extends(parent_module)" (that is, use Erlang's module inheritance)?
   Likewise, "-behaviour"? I saw mention of @@behvaviour but searching for it
   in http://marianoguerra.com.ar/efene/docs/ found nothing.

   - What is the relationship/trade-off between structs and records As a
   side note, I found it surprising that the syntax for records in Efene is
   <record-name>.<variable-name>[<attributes>] instead of
   <variable-name>.<record-name>[<attributes>], it seems reversed from what
   one would expect; some words on why this was chosen would be useful in the
   documentation.

   - Speaking of records, these basically force one to use "-include" of a
   .hrl file if one wants to reuse them across modules (it seems there's no
   way to export a record from an Erlang module, unless I missed something).
   So what's the equivalent in Efene? It would be lovely if one could just
   export records, like one can export types and functions ;-) Oh - one _can_
   export types from Efene modules... right?

   - I saw a reference saying that "Efene doesn't and won't have a
   pre-processor", but I also saw the ability to define $constants and even
   $macroFunctions. So... what's the deal here? Supposing I have a useful
   $invokeFooWithCallerLocation(X) = foo(X, $file, $line), how can I "export"
   both "foo" and "$invokeFooWithCallerLocation" from my module?

   - Finally (and most importantly), I see Efene has come a long way, all
   the way to version 0.9. Does this mean it is stable & mature enough for
   using in a "real-world", non-trivial project?

Thanks,

    Oren Ben-Kiki

Re: [efene] A few newbie questions

From:
Mariano Guerra
Date:
2012-11-28 @ 19:54
Quoting Oren Ben-Kiki (2012-11-05 13:49:32)
> I'm toying with Erlang and I have in my past some experience with Prolog-like
> syntax, enough to know that while it works, "it isn't optimal" :-
> ) So I'm giving Efene a look. I like the fact it is "just an alternative
> syntax" and not a "whole new language", and that there's rebar
> integration.

sorry for the delay, I just saw this mail again :(

> I looked over the documentation and there are a few questions I didn't see a
> clear answer to. Since Efene is basically an alternative syntax, this
> automatically raises the question of "what is the Efene equivalent to the
> Erlang construct X". A "cheat table" in the documentation would
> be very useful... but anyway, here are the questions (and apologies if I just
> somehow missed the answer in the documentation):

I will open issues to the things I have to work on.

https://github.com/marianoguerra/efene/issues/51

>     * What is the proper way to document Efene source code? That is, should one
>       use the Edoc's @doc comments etc.? And would that "just work"
>       with "rebar doc"?

the proper way is to use @doc, I have a tool to generate documentation based
on those annotations, I don't think it works with rebar but maybe a plugin can
be added.

the tool uses sphinx and restructured text to generate the docs so it's not
edoc friendly.

> 
>     * What is the way to have an Efene module specify "-extends
>       (parent_module)" (that is, use Erlang's module inheritance)?
>       Likewise, "-behaviour"? I saw mention of @@behvaviour but
>       searching for it in http://marianoguerra.com.ar/efene/docs/ found
>       nothing.

erlang module level attributes (-extend, -behaviour) should work the same with
@@ at the beggining.

>     * What is the relationship/trade-off between structs and records As a side
>       note, I found it surprising that the syntax for records in Efene is
>       <record-name>.<variable-name>[<attributes>] instead of <variable-
>       name>.<record-name>[<attributes>], it seems reversed from what one would
>       expect; some words on why this was chosen would be useful in the
>       documentation.

about relationship, records are erlang records equivalents, they are converted
to tuples at compiletime and you loose all introspection habilities at runtime.

structs are a json-like structure (in fact internally it uses the same structure
as mochijson so you can work with the from/to json easily), they provide things
like list keys, methods etc.

no reason in particular for the order, I can reevaluate this.

>     * Speaking of records, these basically force one to use "-
>       include" of a .hrl file if one wants to reuse them across modules
>       (it seems there's no way to export a record from an Erlang module, unless
>       I missed something). So what's the equivalent in Efene? It would be
>       lovely if one could just export records, like one can export types and
>       functions ;-) Oh - one _can_ export types from Efene modules... right?

the thing is that erlang's include includes the code in the module that includes
the other file, that's why normally you put them on a separate file, see 
an example:

➜  tmp  cat a.erl
-module(a).
-export([fa/0]).

fa() -> module_a.
➜  tmp  cat b.erl
-module(b).
-export([fb/0]).

-include("a.erl").

fb() -> module_b.
➜  tmp  fnc -t erl2ast b.erl
[{attribute,1,file,{"b.erl",1}},
 {attribute,1,module,b},
 {attribute,2,export,[{fb,0}]},
 {attribute,1,file,{"a.erl",1}}, # here starts a module, completely included
 {attribute,1,module,a}, # -module(a).
 {attribute,2,export,[{fa,0}]},
 {function,4,fa,0,[{clause,4,[],[],[{atom,4,module_a}]}]},
 {attribute,5,file,{"b.erl",5}},
 {function,6,fb,0,[{clause,6,[],[],[{atom,6,module_b}]}]},
 {eof,7}]

there is no thing as exporting types, including a .hrl file will include the
module content on the other one.

>     * I saw a reference saying that "Efene doesn't and won't have a pre-
>       processor", but I also saw the ability to define $constants and even
>       $macroFunctions. So... what's the deal here? Supposing I have a useful
>       $invokeFooWithCallerLocation(X) = foo(X, $file, $line), how can I
>       "export" both "foo" and
>       "$invokeFooWithCallerLocation" from my module?

you can use metaprogramming for that, it's quite experimental but it allows to
generate code at compile time:

http://marianoguerra.org/efene/docs/reference/expressions/metaeval.html
http://marianoguerra.org/efene/docs/reference/expressions/metaevalandastify.html
http://marianoguerra.org/efene/docs/reference/expressions/astify.html

>     * Finally (and most importantly), I see Efene has come a long way, all the
>       way to version 0.9. Does this mean it is stable & mature enough for
>       using in a "real-world", non-trivial project?

it's stable and mature enough, sadly efene doesn't seem to be "interesant"
enough to gather enough community/momentum (some part may be my fault here).

that's why I'm thinking and slowly working on a new version that may be called
efene or something else that is quite similar to efene in syntax but that
provides a simpler, more regular, more powerful syntax and tools that would
allow more user power, I should have a working prototype in the upcoming
months.

this is just so you play with efene but don't invest a lot of effort on it if
you don't want to rewrite it :)

if there is interest in keeping efene as it is alive I may rename the new project
to something else or create a tool that translates current code to the new syntax 
(I don't think there's much code written to justify the effort, but let's see :)

in short "efene is dead, long live efene" :)

> Thanks,

Re: [efene] A few newbie questions

From:
Volker Mische
Date:
2012-11-28 @ 20:41
Hi Mariano,

On 11/28/2012 08:54 PM, Mariano Guerra wrote:
> Quoting Oren Ben-Kiki (2012-11-05 13:49:32)
>>     * Finally (and most importantly), I see Efene has come a long way, all the
>>       way to version 0.9. Does this mean it is stable & mature enough for
>>       using in a "real-world", non-trivial project?
> 
> that's why I'm thinking and slowly working on a new version that may be called
> efene or something else that is quite similar to efene in syntax but that
> provides a simpler, more regular, more powerful syntax and tools that would
> allow more user power, I should have a working prototype in the upcoming
> months.
> 
> this is just so you play with efene but don't invest a lot of effort on it if
> you don't want to rewrite it :)
> 
> if there is interest in keeping efene as it is alive I may rename the 
new project
> to something else or create a tool that translates current code to the 
new syntax 
> (I don't think there's much code written to justify the effort, but let's see :)
> 
> in short "efene is dead, long live efene" :)

Will it still be only syntactic sugar on top of Erlang, or will it be a
completely new language on top of the Erlang VM like Elixir [1]?

[1] http://elixir-lang.org/

Cheers,
  Volker