LFE source directory proposal

[arp...@cryptolab.net]

Hello everyone,

Now that we are heading total rebar3 integration I think we
should support both the src/ directory for Erlang source files
and lisp/ for LFE source files.

Both Erlang and LFE shares the include/ files for records and
macros. I'm not sure what to think of this though.

The reason I'm asking is because I usually end up with
app_module.erl and app-module.lfe on the same src directory
but I admit this is a very minor issue.

Neverless I'd like to ask the list if this idea sounds or
is it worthless to make the difference between both worlds.

Cheers.

[Eric Bailey]

I don't have that issue, but in polyglot Clojure land, the convention is to set src/clj/, src/cljs/, src/frege/, etc. It could be cool to do src/erl/ and src/lfe/. Either way, I don't think a particular approach should be forced by the tooling. With Leiningen (Clojure build tool), you specify a list (vector) of source-paths. Rebar's analog is src_dirs, right?

I think lfex/kla might be useful to you here too.

I'm all for codifying an approach, but forcing it seems too heavy-handed. That's my two cents. :)

Eric

Hello everyone,

Now that we are heading total rebar3 integration I think we
should support both the src/ directory for Erlang source files
and lisp/ for LFE source files.

Both Erlang and LFE shares the include/ files for records and
macros. I'm not sure what to think of this though.

The reason I'm asking is because I usually end up with
app_module.erl and app-module.lfe on the same src directory
but I admit this is a very minor issue.

Neverless I'd like to ask the list if this idea sounds or
is it worthless to make the difference between both worlds.

Cheers.

-- 
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[Robert Virding]

There are some directories that CANNOT be renamed or moved and they are ebin/ and priv/. The runtime system KNOWS about these.

I have no problem in keeping both .erl and .lfe files in the src/ directory, well usually I don't anyway. However, if people want I would no problems with putting .lfe files in the lfe/ or lisp/ directory. One thing I would strongly protest against and that is moving the .erl files out of the src/ directory. This is a convention in all erlang systems, including even elixir, and I think we should keep it.

IMAO this is not a tool question as such as the tools can be made to look wherever you want. However, having a convention for things like this and requesting that people follow it will make it easier for others to know where to look and to find things. Also we can have standard tool configs.

I don't really have a good solution for includes. Maybe have lfe/src/ and lfe/include/ but I don't know.

Robert

On Thursday, 5 November 2015 22:04:48 UTC, Eric Bailey wrote:

I don't have that issue, but in polyglot Clojure land, the convention is to set src/clj/, src/cljs/, src/frege/, etc. It could be cool to do src/erl/ and src/lfe/. Either way, I don't think a particular approach should be forced by the tooling. With Leiningen (Clojure build tool), you specify a list (vector) of source-paths. Rebar's analog is src_dirs, right?

I think lfex/kla might be useful to you here too.

I'm all for codifying an approach, but forcing it seems too heavy-handed. That's my two cents. :)

Eric

On Thu, Nov 5, 2015 at 9:51 AM -0800, <arp...@cryptolab.net> wrote:

Hello everyone,

Now that we are heading total rebar3 integration I think we
should support both the src/ directory for Erlang source files
and lisp/ for LFE source files.

Both Erlang and LFE shares the include/ files for records and
macros. I'm not sure what to think of this though.

The reason I'm asking is because I usually end up with
app_module.erl and app-module.lfe on the same src directory
but I admit this is a very minor issue.

Neverless I'd like to ask the list if this idea sounds or
is it worthless to make the difference between both worlds.

Cheers.

-- 
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[arp...@cryptolab.net]

On 2015-11-05 20:43, Robert Virding wrote:
> There are some directories that CANNOT be renamed or moved and they are
> ebin/ and priv/. The runtime system KNOWS about these.

Yep, by standard they are untouchable.

> I have no problem in keeping both .erl and .lfe files in the src/
> directory, well usually I don't anyway. However, if people want I would
> no
> problems with putting .lfe files in the lfe/ or lisp/ directory. One
> thing
> I would strongly protest against and that is moving the .erl files out
> of
> the src/ directory. This is a convention in all erlang systems,
> including
> even elixir, and I think we should keep it.

As by convention the src/ dir is for .erl files and lib/ is for .ex
files,
I'd go with lisp/ for .lfe files. This would be consistent if one wishes
to
mix Erlang and LFE in the same codebase.

> IMAO this is not a tool question as such as the tools can be made to
> look
> wherever you want. However, having a convention for things like this
> and
> requesting that people follow it will make it easier for others to know
> where to look and to find things. Also we can have standard tool
> configs.

Yes, I was thinking about standarization in the codebase and development
workflow. For instance, it would be nice to have this in the LFE
codebase
as there are plans to start shipping .lfe files *without* having to mix
them
with the core .erl files.

[Duncan McGreggor]

FWIW, I'm not really in favor of having separate source directories for Erlang and LFE. rebar and now rebar3 (with the LFE compile plugin) handle mix-source just fine.

Clojure separates project files based on which JVM language the source is written in, but that's not it's Lisp heritage, it's from the Java (modules/packages) heritage. Everything in the Java world is organized by package/subpackage/namespaces/etc. Erlang doesn't have this legacy... though Elixir tries to hack around that (afaik). The Erlang approach may seem a bit odd if you come from a non-Erlang background (or other programming languages without nested modules/namespaces), but it's the Erlang way and it's easy to get used to: the organization simply moves from directories + files to just files (with name prefixes).

Separating files into different directories would also give a false sense of namespacing, as when the .erl and .lfe files get compiled, they'd get the same .beam name and be in the same ./ebin directory... leaving all sorts of potential debugging nightmares ready to happen. You could, of course, have separate ebin directories ... but this introduces additional complication that I'd rather not deal with by default.

So my vote would be to keep things the way they are by default, knowing that users may do all sorts of fun stuff by updating their rebar.config files with additional src_dirs ... :-)

d

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

[Eric Bailey]

_____________________________
From: Duncan McGreggor <dun...@mcgreggor.org>
Sent: Sunday, November 8, 2015 2:25 PM
Subject: Re: [lisp-flavoured-erlang] LFE source directory proposal
To: Lisp Flavoured Erlang <lisp-flavo...@googlegroups.com>

FWIW, I'm not really in favor of having separate source directories for Erlang and LFE. rebar and now rebar3 (with the LFE compile plugin) handle mix-source just fine.

+1. I've had projects with mixed Erlang and LFE source coexisting happily.

So my vote would be to keep things the way they are by default, knowing that users may do all sorts of fun stuff by updating their rebar.config files with additional src_dirs ... :-)

To this end it might be nice to show an example setup somehow for people who's want the separation, mentioning how all the .beams will live happily together.

[Robert Virding]

OK, then the current suggestion is to leave them in src/. For those who want separate we will suggest they use the directory lisp/, or maybe l_src/.

Would it be possible to have commented out sections in tool config files with the LFE sources in other directories? It is to do in a Makefile but I don't know about rebar or rebar3.

Robert

On Sunday, 8 November 2015 22:15:51 UTC+1, Eric Bailey wrote:

_____________________________
From: Duncan McGreggor <dun...@mcgreggor.org>
Sent: Sunday, November 8, 2015 2:25 PM
Subject: Re: [lisp-flavoured-erlang] LFE source directory proposal

To: Lisp Flavoured Erlang <lisp-flavoured-erlang@googlegroups.com>

[Duncan McGreggor]

I think that's a great idea. We can definitely do that for lfetool as well as new rebar3 lfe templates that generate rebar.config files for LFE projects ...

d

On Sun, Nov 8, 2015 at 6:35 PM, Robert Virding <rvir...@gmail.com> wrote:

OK, then the current suggestion is to leave them in src/. For those who want separate we will suggest they use the directory lisp/, or maybe l_src/.

Would it be possible to have commented out sections in tool config files with the LFE sources in other directories? It is to do in a Makefile but I don't know about rebar or rebar3.

Robert

On Sunday, 8 November 2015 22:15:51 UTC+1, Eric Bailey wrote:

_____________________________
From: Duncan McGreggor <dun...@mcgreggor.org>
Sent: Sunday, November 8, 2015 2:25 PM
Subject: Re: [lisp-flavoured-erlang] LFE source directory proposal

To: Lisp Flavoured Erlang <lisp-flavo...@googlegroups.com>

FWIW, I'm not really in favor of having separate source directories for Erlang and LFE. rebar and now rebar3 (with the LFE compile plugin) handle mix-source just fine.

+1. I've had projects with mixed Erlang and LFE source coexisting happily.

So my vote would be to keep things the way they are by default, knowing that users may do all sorts of fun stuff by updating their rebar.config files with additional src_dirs ... :-)

To this end it might be nice to show an example setup somehow for people who's want the separation, mentioning how all the .beams will live happily together.

--

[Duncan McGreggor]

I've been thinking about this and how it might be "fun" to hack together something that let people organize their LFE code bases in unique and interesting ways, but which ultimately followed the module/beam-file 1-to-1 mapping.

I've done one or two experiments, and I'm planning on adding support for the following in the rebar3 lfe compile plugin:

 * arbitrary nested directories in ./src

 * auto-generation of .beam filenames based on full path and filename under ./src

This would mean that you could have a path structure like src/a/b/c/d.lfe and a .beam file in ./ebin would be created with the name a.b.c.d.beam. Calling this modules functions from LFE code would be the usual: (a.b.c.d:some-func ...). The onus would of course be on the developer to ensure that the module was given the proper name: (defmodule a.b.c.d ...).

Coming back to Ricardo's earlier email, this doesn't totally address his wish list item, but it goes a little in that direction. I *think* that once that code lands, Ricardo could then set his rebar.config with {erl_opts, [no_debug_info,{src_dirs, ["lisp", "erl"]}]} to build the dotted files without a "lisp." prefix to the module.

Anyway, I wanted to say that even though I'm not in favor of having this approach be LFE canon, I think it's a cool feature/possibility for those who might enjoy it :-)

d