[Proposal] Simplify @spec def and @spec defp for efficiency and maintenance purpose

[unif...@gmail.com]

Instead of doing this:

defmodule LousyCalculator do

  @spec add(number, number) :: {number, String.t}
  def add(x, y), do: {x + y, "You need a calculator to do that?!"}

  @spec multiply(number, number) :: {number, String.t}
  def multiply(x, y), do: {x * y, "Jeez, come on!"}

end

How about this:

defmodule LousyCalculator do

  @specdef add(x number, y number) :: {number, String.t} do: 
    {x + y, "You need a calculator to do that?!"}

  @specdef multiply(x number, y number) :: {number, String.t} do:
   {x * y, "Jeez, come on!"}

end

[Louis Pilfold]

Hi

As Elixir has reached version 1 there's not going to be a major change of syntax like this.

You could implement this as a macro in your own project though :)

use MyMacro

def add(x :: number(), y :: number()) :: number() do

  x + y

end

Cheers,

Louis

--
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/ac230011-82c2-4c44-8c4b-58fd163ec081%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[floati...@gmail.com]

Hi Louis 

Thanks for your reply, but I was more thinking of the benefits of having these changes to the whole ecosystem, tooling and everything, not as a personal flavour as a macro.

R.

Fridrik.

[Andrea Leopardi]

Hey Fridrik,

this might improve the language for some and it might not improve it for others, but that's not the most important point. Introducing features like this (that are supposed to have a noticeable impact) to the language is something that try be careful about. One focus of Elixir is to be extensible exactly for this reason: we don't want to add all the nice features out there to the language to avoid having the language become too complex or feature-rich.

Anyways, we usually ask proposals to provide a research-backed rationale for why it would be a good addition to the language, but in cases like this where you can implement the feature yourself, we usually tend to have the community build the feature first and then consider it for inclusion once it's widely used and appreciated.

Now that I went over how we try to deal with this stuff, I'll add my two cents: I am not a fan of this feature since the def* macros today are the main way of defining "code", and this @specdef attribute would change that. Also, Elixir is not a statically-typed language and it's important to understand that Dialyzer is only a static analysis tool. However, I'm afraid having a @specdef like you proposed would suggest that types are something baked into the language instead.

Hopefully this helped clarify the situation.

Andrea Leopardi

an.le...@gmail.com

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/86ba1a45-0214-4a67-a05c-8b79815be2ed%40googlegroups.com.

[Unified Front]

Hi Andrea, thank you for your response.

Understood. It was just a suggestion, which in my humble opinion would get rid of duplication in the source code and eliminate obvious derived maintenance burden thereof.

Simplification like this pays off in the long run, but causes obvious disruption while the change impact ripples through the community and their source code bases.

R.

Fridrik.

  

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BLocLWLnLBg%2B-tZYx%2BwDwankxqhGV60A%2Bkbm53UdmPcvw%40mail.gmail.com.

[Rich Morin]

> On Mar 14, 2019, at 11:56 AM, Unified Front <unif...@gmail.com> wrote:
>
> ... Simplification like this pays off in the long run ...

Other responses have addressed various aspects of your proposal, including:

- maintaining stability in this version of Elixir
- ways to get the proposed behavior using a macro
- desire for a research-backed proposal rationale
- keeping Dialyzer distinct from the base language

However, I haven't seen any comments on the merits of your proposed syntax. So,
because it touches on some issues of concern to me, I'll give it a try...

You use the word "simplification". As Inigo Montoya said in "The Princess Bride",
"I do not think it means what you think it means." Borrowing some language from
Rich Hickey, I'd say that your proposal "complects" @spec and def. That is, it
jams their concerns into a single syntactic mashup. Rather than simplifying the
language's syntax, this would make it even more complicated.

The @def and @spec syntax are already rather complicated, because each has to deal
with a substantial number of concerns. For example, @def has to handle:

- naming of functions and parameters
- pattern matching and dispatching
- argument binding and destructuring
- default values and keyword lists
- guard clauses

I realize that folding type information into function headers is a common approach
in other languages, but I think Elixir's approach keeps the syntax simpler and the
conceptual load lighter. Indeed, I'd like to make the header syntax even simpler.

For example, defguard/1 (https://hexdocs.pm/elixir/Kernel.html#defguard/1) already
lets us extract complicated guard expressions from the function header. However,
I don't know of any equivalent way to extract complex pattern matching expressions
(and defining one is far above my pay grade :-).

Although some might argue that simplicity and complexity are matters of taste, I'd
assert that keeping things simpler (in Hickey's sense) makes them easier for humans
to deal with. When I read a bit of code, my brain has to act a bit like a compiler;
simpler syntax (and logic) give it fewer things that it has to keep on the stack...

-r

[Sven Gehring]

When talking about simplicity, one should not assume that simpler to write (e.g. shorter code) automatically equals simpler to understand.

In my opinion, this syntax adds more confusion for a number of reasons:

- As Andrea mentioned, including type definitions in the function header very likely deceives people into assuming Elixir itself would provide some form of type safety or a fully-fletched type system, which it doesn't.

- @spec Is just metadata for a separate tool (dialyzer). Its use is promoted, since it improves documentation a lot but it is not a core part of the language (unlike function headers)

- For complex types, you would still have to add @type definitions in your module, this would mean function headers would "depend" on documentation metadata to exist, which feels very weird to me.

-sven

--
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/B2C01711-111E-47FF-8A9F-4F4121CF91B2%40gmail.com.

[unif...@gmail.com]

Dear Rich and all the others.

Thank you for your responses.

All your points are beyond valid and bring real weight into this discussion, 

This proposal is partly to provoke a discussion precisely of this nature: 

How can the long term effort/efficiency of development in terms of source code maintenance be improved?

i.e. is it possible to:

1) - keep duplication as small as possible

2) - make sure that any proposed changes don't impact language expressiveness

3) - don't bring in any unwanted type system handicap

This proposal was not intended to offend anyone, just want to point out that in the overall cost of developing a system, 

roughly 80% of the total system development cost comes from maintenance after system delivery. 

All three points above play big part in keeping large complex systems manageable in terms of maintenance.

I think we all agree on the 3 points above, and are really just debating in which order they should be put. :-)

R.

Fridrik.

   

[unif...@gmail.com]

Sven, thank you for your feedback. 

As you probably have read between my written lines by now, I am new to this ecosystem. 

If any of you have taken offence to my suggestion, I do apologise.

No ill intention, I am just looking at this ecosystem with naive eyes of a newcomer.

I am still reading up on this fascinating language/ecosystem - I think I will tread more carefully next time :-)