[erlang-questions] Preloaded modules "lists" dependency

[Ali Sabil]

On Mon, Feb 17, 2014 at 3:14 PM, Loïc Hoguin <essen@REDACTED> wrote:

> Thoughts and ideas are not worth a lot until they are tested so I will
> spare you most details for now. It's still a pretty long read.
>
> For the "Erlang2" part, there isn't much to say. Erlang is a language that
> is almost perfect. My conclusions about improving it are that there are
> very few things that can be improved, and they are mostly edge cases
> (shadowing would be a big one, and not being able to do (<< B:Len/binary,
> _/bits >>, Len) in a function clause would be another - but the latter is
> going to be solved soon as I gather). The rest of it, well, I came pretty
> much to the same conclusions as Joe, the only thing I would add is a basic
> form of metaprogramming. Basically you want to be able to do two things:
> compute some data at compile time, and run tests at compile time (and fail
> to compile if the tests fail). Optionally would allow you to do some
> conditional builds to work around issues with a specific version of Erlang.
> But no macros or other weird stuff that just make the code more complex for
> no good reasons.
>
> I'm no language expert and I'm not too interested in this part so don't
> expect anything from me on that point. If I ever attempt something it would
> just be a very basic wrapper on top of the current Erlang syntax to allow
> for compile-time stuff to happen (meaning: outside functions, and perhaps
> even outside modules entirely).
>
> The "OTP2" part interests me a lot more. One of my favorite ideas is to be
> able to define the whole supervision tree in a single module, and to have
> it feature more complex components like pools for example. It could come
> with a default pool implementation, with a well defined interface (from the
> point of view of the supervision tree) that allows it to be replaced with
> whichever one you want. So instead of having 10 modules describing your
> application, it could all be in a very visual format in a single module.
>

It's already possible as of today. Just pattern match on the init/1
arguments in the supervisor callback module:

start_link() ->
supervisor:start_link({local, ?MODULE}, ?MODULE, app).

init(app) ->
{ok, {
{one_for_all, 5, 10}, [
{workers_sup, {supervisor, start_link, [?MODULE, workers_sup]}, permanent,
infinity, supervisor, [?MODULE]}
 ]
}};
init(workers_sup) ->
{ok, {
 {simple_one_for_one, 5, 10}, [
{worker,  {worker, start_link, []}, temporary, 5000, worker, [worker]}
]
 }}.


> I'm more interested in doing an "OTP2" that targets a different use than
> long running server applications though. As you might already know, I like
> video games, and I have tried a few quick prototypes of games with Erlang.
> I think there is a lot of potential, but the barrier of entry is very high.
> An "OTP2" geared toward games would help greatly. Games typically have a
> main loop. There's basically no way around that today because most graphic
> APIs aren't thread safe. SDL2 was released not too long ago for example,
> and it still isn't thread safe. But that's not a big problem, Erlang's
> concurrency can still play a big part. For example, by making the lists
> module parallelize processing of the list automatically past a certain
> threshold. Or providing efficient timer capabilities (because the timer
> module ain't it). And the processes that access the API can always be tied
> to scheduler 0 to avoid any issues.
>
> I started playing around making an SDL2 NIF this week-end. The first thing
> you instantly win is not having to worry about freeing resources (with a
> few gotchas of course, you can only have so much in memory). The GC does it
> for you! The second thing you instantly win is Erlang's pattern matching.
> The article I wrote about matching tic tac toe solutions directly instead
> of trying to write an algorithm is a good example of that. The code becomes
> small and clear and you can focus on actually building the game.
>
> Of course, for anything to come out of these experiments, I have to find a
> way to not get bored, which may prove difficult. Time will tell.
>
>
> On 02/17/2014 01:30 PM, Pierre Fenoll wrote:
>
>> Hey Loïc,
>>
>> I don't mean to hijack the thread.
>> Can we have more information on "Erlang2/OTP2"? Your guidelines and
>> back-of-a-napkin experiments interest me greatly.
>>
>>
>> Cheers,
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> --
> Loïc Hoguin
> http://ninenines.eu
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140217/48915b35/attachment.htm>