Hello!
What is the advantage of the new syntax? To me it seems it only serves to
obscure what is actually happening.
I don't think adding multiple ways to write the same thing will bring
anything other than inconsistency to the language, causing style squabbles
and giving newcomers one more irregularity memorise.
Side note: if this macro has a special syntax, does this mean I can also
use this syntax for my own macros?
Cheers,
Louis
On 15 Sep 2016 10:39, "Jaap Frolich" <jfrol...@gmail.com> wrote:
> Hi,
>
> @Jose: I would suggest this to be syntactic sugar to import functions from
> modules, that is converted behind the scenes to a call to import, only:
> [...].
> This will add complexity to the language, by creating a new way of
> importing, but in 99% you can use the new syntax, and only use the 'low
> level' syntax in macros or special use cases such as when you need
> 'except'. Another upside is that all the old code keeps working, but we
> have a nicer syntax for new code.
> I think it can incentivize people to only import the necessary functions
> and not import all if there is a nicer syntax to it.
>
> @Onorio: While an improvement, I like the proposed syntax more, because in
> my opinion import a single/a few functions should be the default, and not a
> special case (with using only).
>
> @Norbert: I am not really in favor of the `import &function_one/1,
> &function_2/1 from Module` syntax as I think it is less pretty and while it
> might be easier to implement, semantically it does not really makes sense
> to me / is intuitive.
>
> Thanks for thinking about this :) Love the language.
>
> Cheers,
>
> Jaap
>
>
>
> On Tuesday, September 13, 2016 at 2:54:20 PM UTC+8, José Valim wrote:
>>
>> Thank you Jaap!
>>
>> The benefit of today's syntax is that the arguments are data, which makes
>> them easy to control and manipulate. Imagine you want to dynamically import
>> some data, how do you dynamically build a list or a tuple of {defrecord/2,
>> extract/2} entries?
>>
>> The data syntax is also what you get back from all of the introspection
>> functions in Elixir, such as String.__info__(:functions). Also, today's
>> syntax support `:except` and other options, which are not considered in the
>> new syntax.
>>
>> I would like to see those points considered before further considering a
>> new syntax.
>>
>>
>>
>> *José Valim*
>> www.plataformatec.com.br
>> Skype: jv.ptec
>> Founder and Director of R&D
>>
>> On Tue, Sep 13, 2016 at 6:30 AM, Jaap Frolich <jfro...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Currently when we import a single or a few functions from a module this
>>> is the syntax to do it:
>>>
>>> import Record, only: [defrecord: 2, extract: 2]
>>>
>>> As this is something that is something quite common to do in a module,
>>> the syntax can be more user-friendly in my opinion.
>>>
>>> 1. The notation for a function is captured in data, while normally
>>> we describe functions with the function/arity notation
>>> 2. By default it imports *everything*, as this is often not what you
>>> want, it might be better to make it more explicit
>>> 3. Aesthetics, but that might be personal, I think it does not read
>>> as nice
>>>
>>> So how about having something like below syntax in the language:
>>>
>>> import defrecord/2, extract/2 from Record
>>>
>>> import * from Record
>>>
>>> This might be hard to implement, other candidates could be:
>>>
>>> import {defrecord/2, extract/2}, from: Record
>>>
>>> import {*}, from: Record
>>>
>>> As it might be easier to implement in the language using macros.
>>>
>>> (while we keep the existing import macro around.)
>>>
>>> Let me know what you think!
>>>
>>> Cheers,
>>>
>>> Jaap
>>>
>>> --
>>> 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/ms
>>> gid/elixir-lang-core/4e514d59-05bd-41c6-a1d5-a634b34ff350%
>>> 40googlegroups.com
>>> <https://groups.google.com/d/msgid/elixir-lang-core/4e514d59-05bd-41c6-a1d5-a634b34ff350%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> 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/6c1b1e6e-822b-4540-be41-
> fa65322ed78b%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/6c1b1e6e-822b-4540-be41-fa65322ed78b%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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/CAM-pwt6NmANqj%3D%3DGgZh1CzS0Z%2BE2K%3D%2Bf2wfojnMZ6Z7%3Dt4C17g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
