On Thursday, March 14, 2019 at 9:34:30 PM UTC, Rich Morin 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
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. -- 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/12d6a654-12ff-49c6-bbf3-89f36efdfc60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
