3 ms·

Yes, "path dependence" is a good way to describe it. (And Python has been my favorite language for 16+ years now) For https://www.oilshell.org/ https://www.oi

by chubot 7y ago

Yes, "path dependence" is a good way to describe it. (And Python has been my favorite language for 16+ years now) For https://www.oilshell.org/ https://www.oilshell.org/ , which has Python/JS-like functions, I chose to use Julia's function signature design, which is as expressive as Python's, but significantly simpler in both syntax and implementation: Manual: https://docs.julialang.org/en/v1/manual/functions/index.html#Keyword-Arguments-1 https://docs.julialang.org/en/v1/manual/functions/index.html... Comparison: https://medium.com/@Jernfrost/function-arguments-in-julia-and-python-9865fb88c697 https://medium.com/@Jernfrost/function-arguments-in-julia-an... Basically they make positional vs. named and required vs. optional ORTHOGONAL dimensions. Python originally conflated the two things, and now they're teasing them apart with keyword-only and positional-only params. A semicolon in the signature separates positional and named arguments. So you can have: func f(p1, p2=0, ...args ; n1, n2=0, ...kwargs) So p2 is an optional positional argument, while n1 is a required named argument. And then you don't need * and star star -- you can just use ... for both kinds of "splats". At the call site you only need ; if you're using a named arg / kwargs splat. ---- Aside from all the numeric use cases, which look great, Julia has a bunch of good ideas in dynamic language design. The multiline strings in Julia appear to strip leading space in a way that's better than both Python multiline strings and here docs in shell. Also Julia has had shell-like "f-strings" since day one (or at least version 1 which was pretty recent). Python has had at least 4 versions of string interpolation before they realized that shell got it right 40 years ago :)

chronial 7y ago
But the Julia syntax can not represent arguments that can be passed either positional or named, right?
- ddragon 7y ago
  Yes it can't, unless of course you just make two variables (one positional and one named) and inside the function you choose one. Because of Julia's multiple dispatch paradigm, positional arguments are special compared to named arguments because they decide what method to dispatch to (in Julia f(x) is equivalent to x.f() in object oriented language, and it's extended to all positional arguments). That means that if you called f(a, b=nothing, c=nothing), f(1, c=1) it would dispatch to f(Int64, Nothing, Int64), while if you called f(a; b=nothing, c=nothing) with the same args it would dispatch to f(Int64). In Julia named arguments are effectively a way to pass more arguments without complicating the dispatch rules, and since there is only one way to call a function (outside of optional arguments, which appears to the end user as another implementation of a function) there is no ambiguity to where it dispatches to. So basically, every language has it's own quirks, which the syntax decisions usually reflects, and Julia's scenario is fundamentally different from Python's.
- chubot 7y ago
  Yeah that's true, but I consider it a feature and not a bug. There was a rule in Google's style guide that said to only pass optional arguments with names, and required args without names. It basically enforced this separation while being slightly less flexible, because you can't have optional positional args or required named args. Tens of millions of lines of code was written by thousands of programmers in that style, and it caused no problems at all. On the contrary it made code more consistent and readable.

by chubot 7y ago

chronial 7y ago

But the Julia syntax can not represent arguments that can be passed either positional or named, right?

ddragon 7y ago
Yes it can't, unless of course you just make two variables (one positional and one named) and inside the function you choose one. Because of Julia's multiple dispatch paradigm, positional arguments are special compared to named arguments because they decide what method to dispatch to (in Julia f(x) is equivalent to x.f() in object oriented language, and it's extended to all positional arguments). That means that if you called f(a, b=nothing, c=nothing), f(1, c=1) it would dispatch to f(Int64, Nothing, Int64), while if you called f(a; b=nothing, c=nothing) with the same args it would dispatch to f(Int64). In Julia named arguments are effectively a way to pass more arguments without complicating the dispatch rules, and since there is only one way to call a function (outside of optional arguments, which appears to the end user as another implementation of a function) there is no ambiguity to where it dispatches to. So basically, every language has it's own quirks, which the syntax decisions usually reflects, and Julia's scenario is fundamentally different from Python's.
chubot 7y ago
Yeah that's true, but I consider it a feature and not a bug. There was a rule in Google's style guide that said to only pass optional arguments with names, and required args without names. It basically enforced this separation while being slightly less flexible, because you can't have optional positional args or required named args. Tens of millions of lines of code was written by thousands of programmers in that style, and it caused no problems at all. On the contrary it made code more consistent and readable.