[erlang-questions] Preloaded modules "lists" dependency

[Loïc Hoguin]

On 02/17/2014 04:16 PM, Ali Sabil wrote:
> 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]}
> ]
>   }}.

You missed the "very visual format" part. Basically when I create an 
application I want to write the tree in that module. In the format of a 
tree. Indentation makes seeing how the processes relate to each other. 
Things like that.

>> 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
>>
>

-- 
Loïc Hoguin
http://ninenines.eu