Here's the thing. Right now import doesn't require any special syntax. It's
data driven, and uses elixir structures that already exist and are usable.
Every single option you listed requires changes to the parser, new language
constructs or both. All to do exactly what we can right now. I don't see
the value.
On Thursday, September 15, 2016 at 10:11:09 AM UTC-4, Louis Pilfold wrote:
>
> 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" <jfro...@gmail.com <javascript:>>
> 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/msgid/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-co...@googlegroups.com <javascript:>.
>> 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/dcf7a18a-42e5-4757-af61-9c3f4e8b4bee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
