[erlang-questions] Preloaded modules "lists" dependency

[Thomas Lindgren]

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




On Monday, February 17, 2014 3:43 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.
>
>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
>
>
>

Take a look at this: https://github.com/thomasl/gen_app

Here is one application I just started:

  1> gen_app:app_sup(om, [{sup, {sup, om, [om_ets_owner, om_repository_server, om_code_server]}).

Which starts a (dynamic) application 'om' with a supervisor 'om' handling three gen_servers on localhost.

Caveats: Somewhat inelegant notation so far, and you still need 'application' for the more complex cases. No pool handling at the moment either. But it's pretty compact.

Best,

Thomas

PS. Apologies to those I've written to recently -- Yahoo is acting up, perhaps due to THE HUGE THREADS we're having, so I'm having some trouble reading my mail at the moment. Sporadically hanging client, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140217/b12c019e/attachment.htm>