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 :-)
On Thursday, March 14, 2019 at 10:21:17 PM UTC, Sven Gehring wrote: > > 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 > > On Thu, 14 Mar 2019 at 22:34 Rich Morin <r.d....@gmail.com <javascript:>> > wrote: > >> > On Mar 14, 2019, at 11:56 AM, Unified Front <unif...@gmail.com >> <javascript:>> 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 >> >> -- >> 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/B2C01711-111E-47FF-8A9F-4F4121CF91B2%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/a978dc5b-4e47-44b0-b7d4-023d8ec633fa%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
