[elixir-core:7706] Re: make functions with @doc false visible in IEX autocompletion

[Robert Virding]

That sounds weird.


On Wednesday, 20 December 2017 10:51:29 UTC+1, Milad Rastian wrote:
>
> I've noticed in Elixir 1.5 we don't autocomplete functions that have @doc 
> false.
>
> For example if I create a module like this
>
> defmodule MyApp.Accounts.User do
>   use Ecto.Schema
>   import Ecto.Changeset
>   alias MyApp.Accounts.User
>
>
>   schema "users" do
> field :age, :integer
> field :name, :string
>
> timestamps()
>   end
>
>   @doc false
>   def changeset(%User{} = user, attrs) do
> user
> |> cast(attrs, [:name, :age])
> |> validate_required([:name, :age])
>   end
> end
>
> And now if I try to use it in iex, I won't get autocompletion suggestion 
> for changeset function.
>
> iex(1)> MyApp.Accounts.User. changeset>
>
>
> I believe this behavior is changed since this PR 
> https://github.com/elixir-lang/elixir/pull/6131
>
> In terms of user experience is a bit unexpected that in the above example 
> I have a public function changeset and I can't get suggestion it in IEx. I 
> use IEx regularly when I want to check something quickly and it happened to 
> me few times so far and I was really confused why I can't get suggestion 
> for my public function.
>
>
> Looking forwards to hear your opinions
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/23e21b34-1e57-45fa-a62d-a77bd28aa0d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7175] [Proposal] Sorted Map and Sorted Set

[Robert Virding]

I am just curious: what is your use case?

If you look in my luerl system, https://github.com/rvirding/luerl, you will 
see a module ttdict.erl which uses 2-3 trees. These are basically the same 
as red-black trees. Well, actually, rb trees are sort 2-3 trees but only 
using binary nodes. I have not done any serious speed comparison but my 
guess is they should be about as fast s rb trees. An easy way to handle the 
slowness of size would be to carry around an explicit size field. the 2-3 
trees and rb trees have the same interface as dict.

For fun I also implemented aa trees and sets, which Arne Andersson trees.

Data structures are fun.

Robert

P.S. I use 23-trees in luerl as maps are missing one very important 
function needed for implementing Lua and that is to be able to efficiently 
step through a tree. I need a 'first' function which returns the first 
key-value pair and then a 'next' which returns the next pair after a given 
key. Order is unimportant but I need guarantees that I will see all pairs.

On Sunday, 28 May 2017 09:19:59 UTC+2, Ricky Han wrote:
>
> Hi José,
>
> I posted an update on the benchmark here [1].
>
> [1] https://github.com/elixir-lang/elixir/issues/6161
>
> Best,
> Ricky
>
> On Wednesday, May 24, 2017 at 7:20:58 AM UTC-4, José Valim wrote:
>>
>> Thanks for the proposal Ricky Han!
>>
>> It is also worth mentioning the red black trees library from Robert 
>> Virding: https://github.com/rvirding/rb
>>
>> While having a library is already great for the ecosystem, we can 
>> consider this being added as part of Elixir given Elixir doesn't have an 
>> indexed data structure besides tuples (which are expensive to transform).
>>
>> However, there is a lot of work to do before we are able to fully 
>> evaluate it:
>>
>> 1. As you said, it needs documentation. You mention the 1990 look and 
>> feel from the Erlang libraries but they are at least *documented*
>>
>> 2. We need to validate the claims it is fast and space efficient. Have 
>> you benchmarked it against gb_trees and gb_sets and measured 
>> insertion/retrieval/deletion times as well as memory usage? For example, 
>> your implementation uses maps for nodes and using tuples will likely be 
>> much more efficient
>>
>> The core team has discussed adding indexed data structures multiple times 
>> in the past but we haven't found something that feels right.
>>
>>
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R&D
>>
>> On Wed, May 24, 2017 at 11:10 AM, Ricky Han  wrote:
>>
>>> The most important data structure elixir is missing - *sorted, ordered 
>>> sets and maps*. Say what? Elixir only has non-ordered sets. The 
>>> default(recommended) map is HashMap whereas Haskell Data.Map is backed by 
>>> binary tree. JVM, stdlib, .NET are treemaps too. This is strange because 
>>> there is 0 penalty for functional language to use trees.(sidenode: Redis 
>>> uses skip lists which is bad for immutability).
>>>
>>> These are actually several solutions out there:
>>>
>>> :orddict, :ordset, :gb_sets, :gb_trees
>>>
>>> :orddict and :ordset are very bad as they are backed by lists and have 
>>> linear time complexity.
>>>
>>> :gb_sets and :gb_trees are performant because they are backed by AA 
>>> trees. However, annoyingly they don't track size of subtrees which means 
>>> can't be indexed unless converted to list(expensive).
>>>
>>> Here is why this would be better than all the existing solutions and 
>>> should be integrated into elixir stdlib.
>>>
>>> 1. Being able to index keys means we can it can replace Redis sorted set 
>>> completely. With ZRANK, ZRANGE abilities
>>> 2. All the other languages have it
>>> 3. Proves to be fast and space efficient
>>> 4. First class citizen so no need to use inferior Erlang library with 
>>> limited functionalities and 1990s documentation
>>>
>>> I find sorted sets and maps very useful in other languages(especially 
>>> ruby). So like a good hacker I ported red black tree from Haskell[1] 
>>> Currently, both data structures are functional but documentations are few 
>>> and far between.
>>>
>>> [1] https://github.com/rickyhan/rbtree
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from i

Re: [elixir-core:7124] Pipe and anonymous functions

[Robert Virding]

Actually this was said by Dijkstra long before Rich:

“Simplicity is a great virtue but it requires hard work to achieve it and 
education to appreciate it. And to make matters worse: complexity sells 
better.”
Unfortunately all 3 points are true. He also said:

“Simplicity is prerequisite for reliability.” 

which is also true.

On Tuesday, 9 May 2017 14:11:46 UTC+2, Onorio Catenacci wrote:
>
> To paraphrase Rich Hickey--"Simplicity isn't easy".  Figuring out those 
> simple function signatures is not the first thing that comes to mind for 
> most of us.  But it's worth the effort.
>
>
> On Saturday, May 6, 2017 at 7:14:45 PM UTC-4, Josh Bourgeois wrote:
>>
>> I thought of practicing, but then I just wound up doing a lot of 
>> thinking. Then it clicked 😬
>>
>> defmodule Words do
>>   def count("" <> string), do: parse(string) |> Enum.reduce(%{}, &count/2)
>>
>>   defp count("", map), do: map
>>   defp count("" <> word, map) do
>> word |> String.replace("_", "-")
>>   |> increment(map)
>>   end
>>
>>   defp increment(word, map), do: put_in(map[word], (map[word] || 0) + 1)
>>   defp parse(string), do: string |> String.downcase |> 
>> String.replace("-", "&hyph;") |> String.replace("_", "-") |> 
>> String.replace("&hyph;", "_")  |> String.split(~r/\W/u)
>> end
>>
>> It's just a challenge to think of meaningful names sometimes. Breaking 
>> function/method bodies into smaller discrete blocks of work is obviously a 
>> fundament to making code more readable, but it takes discipline and, 
>> sometimes, a thesaurus
>>
>> Thank you for entertaining this zombie discussion once more 😶
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/59c6d90d-ded2-4794-8a73-920ab9350007%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:7059] Exception protocol

[Robert Virding]

How do you mean "returning exception structs"? Isn't an exception something 
which is raised?

Robert


On Tuesday, 4 April 2017 16:45:57 UTC+2, OvermindDL1 wrote:
>
> I am a *huge* fan of returning exception structs instead of raising them, 
> a few libraries follow this style as well like `exceptional` on hex.pm.
>
> However, if you are wanting to format it, look at the Exception.message 
> function, it takes an exception and formats it properly by looking at a 
> message field on the struct or calling the modules message/1(?) function or 
> whatever.
>
>
> On Monday, April 3, 2017 at 9:27:04 PM UTC-6, José Valim wrote:
>>
>> Btw, if I understand your concerns correctly, libraries tackle this by 
>> returning exception structs. See DBConnection for an example.
>> -- 
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R&D
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/9d04c8d9-7496-4eea-955f-008d19fc523a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elixir-core:6895] Re: Sorting maps when inspecting

[Robert Virding]

How do you mean "when they are inspected"? If you do it then all functions 
which step through the keys would have to be fixed and some like *fold* and 
*map* could be very difficult to implement in an efficient manner. If you 
don't do it for all then it is pointless.

Robert


On Monday, 13 February 2017 22:49:13 UTC+1, Eric Meadows-Jönsson wrote:
>
> Currently struct and map keys are in indeterminate order when they are 
> inspected. Due to implementation details in the VM maps that have <32 keys 
> are in term order but for larger maps and structs the order is random.
>
> I propose always sorting the map keys when they are inspected so that it's 
> easier to read and scan the results.
>
> -- 
> Eric Meadows-Jönsson
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/5e3f4e37-bb6c-4688-bb86-5d430e095726%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6574] Proposing Tuple.deftuple(p)/2, complementary to existing Record.defrecord(p)/3

[Robert Virding]

How do you mean a "functional interface". One issue with pattern matching a 
tuple is that you have to write the whole tuple. There is no way of saying 
to test if it is a tuple and is the Nth element 42. The (erlang) record 
interface does this expansion in a pattern, it expands the more functional 
interface to the right sized tuple where the first element is the record 
name, the elements in which you are interested to the patterns you give and 
all the other elements become _ so as to match anything[*]. So a tuple 
interface must do the same thing, which is why I was asking about the 
functional interface.

Robert

[*] You can do the "matching" in a guard if you wish but then the macro 
becomes more complex. The record interface expansion in the body is the 
basically same except that instead of _ for the other elements there is the 
default values.

On Friday, 4 November 2016 14:46:54 UTC+1, Waldemar Rachwał wrote:
>
> Only skimmed Inspect.Algebra... Could those macros give possibilities to 
> achieve what Record.defrecord/3 provides? Among other things: 
> pattern-matching capabilities, "tell me index of the field by name"...
>
> Maybe I should have avoided dwelling on my use case, and formulate more 
> general wish: Shouldn't tuples get functional interface 'a la' existing 
> records, but for tuples in general, not necessarily for tuples being at 
> once 'records'?
>
> Regards,
> Waldemar.
>
> On Fri, Nov 4, 2016 at 1:21 PM, José Valim  > wrote:
>
>> In such cases, I use macros:
>>
>>
>> https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/inspect/algebra.ex#L158-L176
>>
>> Right now it feels this is a very specific use case to justify being 
>> added as part of Elixir.
>>
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R&D
>>
>> On Fri, Nov 4, 2016 at 1:19 PM, Waldemar Rachwał > > wrote:
>>
>>> Hello,
>>>
>>> The rationale behind the proposal is the fact there are cases the 
>>> records can be inappropriate. They provide excellent interface, but well, 
>>> sometimes the tag atom at first position (index 0) rather harms than helps.
>>>
>>> One such use case I found when dealing with ETS tables.
>>>
>>> ETS entries are tuples. While entries are homogenic, one record 
>>> definition which tuple data looks like {:tag, key, field1, ...} seems to be 
>>> a good fit and only one has to tell ETS the key is at second position 
>>> (index 1).
>>>
>>> However, when it comes to store many tuples of different shapes in one 
>>> table, the key itself should differentiate these shapes and the instance 
>>> within given shape, something like {:tag, key}, and then the alone :tag 
>>> field of a record becomes quite redundant. In such heterogenic ETS tables, 
>>> existing records have also their own use: for example to hold singular 
>>> entries each with "global" counters as fields.
>>>
>>> Obviously, this is the real use case I encountered. Perhaps there are 
>>> others. I have no doubt that generally records, in cases one wants to use 
>>> tuples via functional interface, will be default practice.
>>>
>>> I have code ready because I used the stuff earlier from an auxiliary 
>>> module. In Elixir the Tuple module and deftuple(p) seem natural, but I was 
>>> never good at naming things...
>>>
>>> What do you think?
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elixir-lang-co...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/elixir-lang-core/CABR-7m0R8j52Y2r57-hWomJ-nz%2B0R0Q5Q01B-xm5CAZH0jGHbw%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elixir-lang-co...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LVgRU7j1tAfUS0kY2PUDj44j6D7LUkNiK_tTofsAR4UQ%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/69b83195-e8d6-4866-953c-0c5

[elixir-core:6284] Re: Kernel.compare/2 and Comparable protocol

[Robert Virding]

I have missed most of the discussion but it feels strange that a function 
in Kernel, Kernel.compare/2, results in calls to a protocol. For me Kernel 
feels like being at the very base and should not call anything outside it, 
irrespective of whether it is part of elixir core or not.

Robert

On Sunday, 7 August 2016 22:13:45 UTC+2, Michał Muskała wrote:
>
> Hello everybody, 
>
> Today I’d like to address one of annoyances of working with elixir - 
> comparing structs. It’s a problem because of two reasons: 
> - it’s not widely known that the regular comparison operators do not work 
> correctly with structs 
> - there’s no standard way of providing custom comparison function. 
> This issue is especially apparent in couple libraries, most notably Ecto 
> (with calendar types), decimal and with the new standard calendar types. 
>
> I propose adding a Kernel.compare/2 function with signature: 
> compare(term, term) :: :lt | :eq | :gt 
>
> I would propose following properties of the function: 
> - inlined implementation for built-in types, only for both arguments of 
> the same type 
> - for structs the function calls the Comparable.compare/2 protocol 
> function 
> - implementation for structs are allowed to return value for two different 
> types when it makes sense 
> - the protocol is also implemented for built-in types 
> - the protocol does not fallback to Any 
>
> I’m convinced this will allow for much easier experience when comparing 
> structs, even though the VM does not allow to extend the regular comparison 
> operators. 
>
> Michał. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/84475239-f29b-4dd5-a903-810fab453489%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:6045] Proposal: add native language support for handling Decimal types

[Robert Virding]

I am getting in this discussion very late but I think getting a change in 
the Erlang VM to support this would be very difficult. It would require 
adding a new, very specific data type and I don't see that happening. Sorry.

Robert

On Tuesday, 5 July 2016 15:07:13 UTC+2, Benjamin Scherrey wrote:
>
> Rules regarding rounding and how to distribute the "leftovers" in 
> financial ledgers are critical in financial transactions and belong, 
> properly, in the types and operations of those types. It may be an 
> implementation detail that we utilize thousandths of a unit integer 
> representation behind the scenes but that is only a small part of the 
> design necessary to execute code in a financial domain effectively.
>
> I do agree with Onorio's comment (paraphrased) that working code speaks 
> louder than theory. Unfortunately I don't know enough about the language / 
> compiler implementation especially regarding guard types to provide such 
> code. My limited (and quite possibly incorrect) understanding seems to 
> suggest that the way I would think of doing it likely requires an upstream 
> change in the Erlang VM. This is the question that I am most curious about 
> regarding feasibility of such a type. 
>
>   - - Ben 
> On Jul 5, 2016 6:46 PM, "Dmitry Belyaev" > 
> wrote:
>
>> I'm not sure that decimal type is a must. All the handling can be done on 
>> integers representing cents or 0.1 of a currency or whatever is the 
>> required precision, and format the value as appropriate when presenting. 
>> That way you don't have all the complications with guards and arithmetic 
>> operators.
>>
>> On 1 July 2016 7:38:00 AM AEST, elxi...@gmail.com  wrote:
>>>
>>> First of all thanks everyone the constructiveness and the great ideas.
>>> I'm new to Elixir, so please forgive me if I've some bad assumptions.
>>>
>>>1. Supporting number format like 1.32f or 12.45d, etc would be great
>>>2. Regarding using the regular arithmetic operators like +, -, * and 
>>>/ for decimal type, I fail to see why it would be slower for integers 
>>> for 
>>>example. At the end I'd assume only the generated byte code matters. So 
>>> why 
>>>not generated the usual byte code when integers or floats are used and 
>>>generate some advanced logic when the operands are of decimal type?
>>>3. Guards, following Peter's suggestion and using some logic for 
>>>byte code generation (as mentioned in point #2) again I think it would 
>>> be 
>>>possible to handle decimal types transparently.
>>>4. I think simplifying a couple of things, like handling the decimal 
>>>types (which is a must for financial apps)/removing boiler plates, would 
>>>have a positive effect on language adoption as well
>>>   - I know it's off-topic, but it might worth mention that such 
>>>   simplifications could do wonders, Elixir is great language but why 
>>> not make 
>>>   even better out of the box, like:
>>>  - instead of specifying a method like this:
>>>  @spec add(number, number) :: number 
>>>  def add(x, y), do: ...
>>>  
>>>  it would be far easier to write it a single line like this:
>>>  defs add(number x, number y) :: number, do: ...
>>>  - or embrace the familiar lambda syntax for defining in-line 
>>>  functions, so that parameters could be referenced by their name, 
>>> instead of 
>>>  their position
>>>  - etc
>>>   
>>>
>> -- 
>> Best wishes, 
>> Dmitry Belyaev
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elixir-lang-co...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/D5A1728D-A38F-4D26-A586-46D4924A5463%40gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/e26b6df7-3f8b-4392-8afd-21d69e221718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5881] Test grouping and named setups

[Robert Virding]

Are there any plans to move towards adapting and using Common Test? It is 
much more oriented towards testing systems with many ways of grouping (:-)) 
and controlling tests.

Robert

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/ed1cbef5-8f9a-4d2e-a1ae-c1d5b3979a5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5789] Self-hosted Elixir?

[Robert Virding]

It would definitely make it more difficult to download the sources and 
build a release. You would need quite a few pre-compiled modules to do 
that. Now all you need is Erlang which you need anyway to run the system.

Robert

On Monday, 23 May 2016 10:34:52 UTC+2, José Valim wrote:
>
> A self-hosted compiler is honestly very low priority. The benefits are 
> very small compared to the complications required for bootstrapping the 
> language, which would likely include keeping a list of precompiled modules 
> in the source so we can bootstrap without having Elixir pre-installed.
>
>
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
> On Mon, May 23, 2016 at 7:20 AM, Daniel Azuma  > wrote:
>
>> Hi all,
>>
>> I've been working off and on for a few months on an Erlang->Elixir 
>> transpiler (mostly as an exercise for myself to learn Erlang semantics). I 
>> recently had the idea of applying it to the Erlang code in the Elixir core, 
>> creating a version of the Elixir compiler written completely in Elixir. 
>> Long story short, there are some caveats in the build process and a few 
>> bugs in the transpiler to work around, but today I finally got a proof of 
>> concept working and passing the tests.
>>
>> So I was wondering whether the possibility of self-hosting the Elixir 
>> compiler had been discussed before. My initial thoughts were that it's 
>> often interesting to self-host; however, in this case all the core code 
>> would have to remain written in a "bootstrap" style of Elixir without 
>> access to the standard library, which might be awkward. But I was curious 
>> what else might have been discussed and what people's thoughts were.
>>
>> Thanks,
>> Daniel
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elixir-lang-co...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/76F2675C-E59D-40C1-80F7-D057984781E9%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/0b5ce71a-a288-4dd5-8300-c7e3482ff735%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elixir-core:5729] Elixir on vm R16

[Robert Virding]

I can just say the LFE compiles and runs on R16 as long as you don't use 
maps.

Robert

On Sunday, 15 May 2016 02:26:06 UTC+2, Peter Hamilton wrote:
>
> Elixir is heavily dependent on Maps, which didn't show up until Erlang 17.
>
> That means most of the ecosystem is not available to you, regardless of 
> which path you choose. The benefit of Elixir at that point is basically 
> syntactic sugar and macros. (Protocols are only partially useful without 
> Structs, and structs require maps.)
>
> If you plan on doing heavy macro work I'd recommend LFE. If you just want 
> syntactic sugar, I'd say forget it and just do Erlang.
>
> On Sat, May 14, 2016, 1:54 PM Damien Krotkine  > wrote:
>
>> Hi,
>>
>> I'm currently coding quite a lot of things as Erlamg hooks in Riak for 
>> work ( Booking.com ). Riak currently runs on R16. These hooks have to be 
>> loaded and running under the same VM as Riak, so 16.
>>
>> I'd like to code them in elixir instead, but Elixir requires 18. I 
>> thought about:
>>
>> - using an old Elixir, but it doesn't sound right.
>> - try to compile Elixir on R16, and violently discard what doesn't 
>> compile, or replace it by older versions. But that sounds like a lot of 
>> work.
>> - use current Elixir, don't use features and modules that won't work on 
>> R16, and hope for the best.
>>
>> Then, after attending ElixirConf EU in Berlin, having a lot of talks with 
>> various people, I thought maybe there are better ways to do it, that I'm 
>> unaware of.
>>
>> So is there an easy way to use latest Elixir to produce beam bytecode 
>> that runs properly on an older beam VM?
>>
>> Also, what is the Elixir philosophy about backward compat, in term of 
>> bytecode,  feature and syntax?
>>
>> Finally, maybe I'm completely wrong about all this. In this case let me 
>> know, as I'm quite new to Elixir and I have no idea what I'm doing.
>>
>> Thanks,
>> Dams
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "elixir-lang-core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elixir-lang-co...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/FC47A718-6C04-4FFC-8C48-767651B29DE5%40gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/99fcb761-dd42-467a-9d57-2f4184576e2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.