Improvement: the syntax for importing functions from modules

[Jaap Frolich]

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

[José Valim]

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

--
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+unsubscribe@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.
For more options, visit https://groups.google.com/d/optout.

[Onorio Catenacci]

Hi Jaap,

Is your basic concern the 

[function: arity]

notation as opposed to the 

function/arity 

notation used in other places?  I mean are you basically asking for the notation to be unified?  If so, would [function/arity, function/arity] suffice assuming it were supportable?  Something like 

import Record, only: [defrecord/2, extract/2]

Just trying to understand the basis of your proposal.

oc

[Norbert Melzer]

I do not like the new python-like syntax for import, but to be honest, I do like to specify functions in `name/arity` instead of `{name, arity}`.

Perhaps we can either build upon the division operator in the AST or we use the capture syntax as in `import Enum, &map/2`. This should be just an addition to the "old" tuple notation and is getting converted into it.

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.
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/CAGnRm4KLGhV34Xu_Ry8g1_VZPKtrju%3DQPiiZ5y7Ss8U8nAtpUw%40mail.gmail.com.

[Dmitry Belyaev]

I personally find the reversed order of imports such as in python or typescript very unnatural. Consider tools that could suggest what is available to import. You first write the module for them to work, don't you? At least I do write 'import {} from module' in typescript and only then choose what actually I import. So to me the current Elixir way has far more sense.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Jaap Frolich]

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

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

[OvermindDL1]

To me it makes significantly more sense to list the module first, then the things that are being excluded/included, as that is how it is used everywhere.  The way Elixir does it now makes the most sense and I would not opt for reversing it.

You could, however, make a library with a macro that does something like what you wish.

[Louis Pilfold]

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

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@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.

[Ben Wilson]

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.

[Onorio Catenacci]

I am -1 (almost - 2) on more syntactic sugar. I don't think the current syntax is difficult or confusing so I don't believe adding sugar over it is really gaining anything.

oc

You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/s5G9CWE8REA/unsubscribe.
To unsubscribe from this group and all its topics, 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/dcf7a18a-42e5-4757-af61-9c3f4e8b4bee%40googlegroups.com.

[Pedro Medeiros]

Yeah I'm with Onorio with the -1 . I don't see any gain with this new syntax and also the currently one resemble more the same syntax for erlang code.

To unsubscribe from this group and all its topics, send an email to elixir-lang-core+unsubscribe@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.

--

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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAP%3DvNq8uPmtGiEgLNRma2V%3D1OnJjGNdY2uzfAof%3DYWUKk0f4-g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Pedro Henrique de Souza Medeiros
----------------------------------
Cel: +55 (61) 9197-0993
Email: pedr...@gmail.com

Beautiful is better than ugly,
Explicit is better than implicit,
Simple is better than complex,
Complex is better than complicated.

The Zen of Python, by Tim Peters