Timeline for What negative consequences can arise from this language design rule?
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 10, 2014 at 12:57 | audit | First posts | |||
| Apr 10, 2014 at 12:57 | |||||
| Mar 19, 2014 at 17:59 | vote | accept | jcora | ||
| Mar 19, 2014 at 17:59 | history | bounty awarded | jcora | ||
| Mar 14, 2014 at 22:04 | comment | added | jcora | @Doval Hi, I think I've arrived to an acceptable solution, if you have the will check out my answer below and tell me what you think. | |
| Mar 13, 2014 at 23:11 | comment | added | jcora | @Doval well a REPL wasn't really planned anyway. This is a hobby project, and the language will be a compiled one (to machine code, not bytecode) - like C. | |
| Mar 13, 2014 at 22:59 | comment | added | Doval | @yannbane Fair enough, I see that now. I still feel the semantics are unnecessarily surprising though. It probably precludes having REPL, too, since you need to read ahead to the end of input. | |
| Mar 13, 2014 at 22:07 | comment | added | jcora | You've already created at least one inconsistency, and a particularly damning one at that - treating functions differently from other values. - I disagree on this too. I'm not treating functions differently, it's just that def has a special meaning - to hoist the function along with its definition. def x() = 5 means that you can write x() anywhere in scope and it will be evaluated to 5. | |
| Mar 13, 2014 at 21:21 | comment | added | Doval | @yannbane Yup. The asterisks are there for emphasis (I had hoped I'd be able to make it bold, but no such luck.) By using and to tie two function declarations together, the compiler understands that they're being introduced simultaneously and will allow mutual recursion. As a side bonus it's extra clear to human readers as well. @Mahdi My bad! That's fair. | |
| Mar 13, 2014 at 21:11 | comment | added | jcora | @Doval I don't understand your example of different syntax, could you please elaborate? Is **and** a part of code that somehow "ties" name1 and name2 so that they can be used recursively? | |
| Mar 13, 2014 at 19:57 | comment | added | Mahdi | @Doval Let me mention it again that I'm totally agree with your points. What I'm trying to say is that in my opinion it will increase the maintenance efforts dramatically, and as a programmer I hate to face debugging it. If I want to rephrase your last sentence it will be something like: "I'll refactor my code in a way that eliminates need of inner f()." -- Again, I totally see your point within the example. | |
| Mar 13, 2014 at 19:49 | comment | added | Doval | @Mahdi Why is that? I prefer not to make use of shadowing, but most people understand how it works. However, at first glance you'd expect f() to call the first definition. That's what I find so troubling about it - it violates the principle of least surprise. I realize the example is a bit contrived, but it's not too hard to imagine some additional code below the second definition, following this train of thought: "I'll make use of the outer f() first, then shadow it and use the new definition." | |
| Mar 13, 2014 at 19:14 | comment | added | Doval | @yannbane For mutual recursion you can use special syntax. For example, Standard ML uses fun name1 arg1 = <expr1> **and** fun name2 arg2 = <expr2> | |
| Mar 13, 2014 at 19:12 | comment | added | jcora | Concerning your last example, yes that is very problematic. However I'd say that I'm OK with not being able to call the outer functions with the same names as the inner ones - that's just shadowing. | |
| Mar 13, 2014 at 19:10 | comment | added | jcora | Your first post just seems to reject the entire concept of hoisting functions, but I don't see how I can not use it. If I only allow users to refer to functions after they are defined, this seems to severely limit the expressive power of the language. Mutually-recursive function definitions, are not possible for example. | |
| Mar 13, 2014 at 19:09 | comment | added | Mahdi | @Doval I'm totally agree with your points, but I believe if you change the function definition like what you did in your last example, then your program deserves to crash :) | |
| Mar 13, 2014 at 19:05 | history | edited | Doval | CC BY-SA 3.0 | Clarification on final paragraph |
| Mar 13, 2014 at 19:05 | comment | added | jcora | (I'm gonna pick a part of your answer to reply to in each comment, they're too limited for a proper reply) Redefinitions are impossible when using the named function syntax. I'm treating functions as values, but the names they get assigned to are equivalents of final in Java, const in C, or val in Scala. There are regular variables that can't get reassigned as well. | |
| Mar 13, 2014 at 18:57 | history | edited | Doval | CC BY-SA 3.0 | Typo |
| Mar 13, 2014 at 18:46 | history | answered | Doval | CC BY-SA 3.0 |