https://futureofcoding.org/ logo
Join SlackCommunities
Powered by
Has anyone seen examples of languages that only us...
# thinking-together
n
Has anyone seen examples of languages that only use named parameters (a.k.a. keyword args, as opposed to positional parameters) and also support first-class functions? Looks like these features become messy when combined since now your type signatures ask for e.g. "a function named f with parameters x and y", whereas the function named g that you intend to pass as an argument has parameters a and b, so then you have to make a wrapper function around it.
šŸ¤” 1
ā¤ļø 2
a
Interesting question. I was thinking that only named parameters might be a good idea, but it never occurred to me that this problem would pop up. Maybe pattern matching on types, and all passed types must be different (e.g. via newtypes)?
šŸ‘ 1
k
Thereā€™s a reason why naming is often called one of the hard problems in programming!
šŸ’” 3
šŸ˜„ 1
p
s
Smalltalk!
Arguably it doesn't have functions so not what you're looking for.
w
Yes, about Smalltalk, you can think of methods as having named parameters or as selectors justbeingnameswithcolonsinthem: using positional parameters. Ultimately anytime you have more than one positional parameter, plumbing is going to become an issue.
n
@Prathyush Are you able to point me more precisely to what you're referring to? From a quick browse of the paper it appears Piccola functions use positional parameters.
@Adrian Sieber that's one possible approach, but I think it would still force you to do the same amount of wiring since you'll probably have to newtype things for each instance where you'd otherwise use a wrapper function.
y
Lamdu. There a function call with multiple arguments is just a syntax-sugar for a parameters record. The concern you raise is real and we havenā€™t quite addressed it yet but I believe that it will also be solved with some projectional syntax sugar.
šŸ˜Æ 1
n
Interesting! I'll keep my eye on your progress šŸ™‚
@yairchu Under what circumstances do you bump into this problem when writing lamdu code? Does it come up often?
p
Ah sorry about that, looks like I shared an earlier treatment of the language oriented on describing it's mathematical model. Here's a later work, that focuses on how non-positional parameters, what they call "Forms" enable compositionality: http://scg.unibe.ch/archive/papers/Ache01aTour.pdf Also this paper seems very relevant to the discussion here. Explicit namespaces: http://scg.unibe.ch/archive/papers/Ache00bExplicitNamespaces.pdf
n
@Prathyush thank you šŸ™‚ I'll have a read
y
@Nick Smith actually now that you ask, we already solve some of the problem with syntax sugar
d
@Nick Smith
"a function named f with parameters x and y", whereas the function named g that you intend to pass as an argument has parameters a and b, so then you have to make a wrapper function around it
Why do you need to make a wrapper?
a concert examples of what your describing:
Copy code
(defn foo [{:keys [f m]}] (f m))

(defn g [{:keys [a b]}] [a b])

(foo {:f g
      :m {:a 1 :b 2}})
;; => [1 2]
are we calling 
{f g :m ...
a wrapper?
In a small example that might seem like overhead, but in general its not. The caller function is describing things in one context, the arguments are named/mapped to it.
You can put syntax sugar ontop of this, but then it requires readers to know that they have changed context, so the usefulness there will be... situational?
y
@Drewverlee the syntax sugar I showed doesnā€™t hide the conversion, it just displays it very succinctly
d
sure, but it seems like now there are two legal ways to display the same information. I agree most of the time, this conversation will make things more clear.
y
@Drewverlee with projectional syntax sugar code is always displayed a certain way. You canā€™t write it so that itā€™s in the other way (it will automatically get sugared if it fits the pattern).
d
@yairchu how does it display outside the structural editor? E.g GitHub?
y
@Drewverlee yeah weā€™ll ā€œjustā€ have to reimplement GitHub too..
d
To be clear, I think the "suger" is great.
šŸ™‚ 1
a
I'm a big fan of this concept. I think positional parameters are bad, unless they're a list. But they sure are convenient in most cases. I read about one language whose name I can't remember where parameters are named by their type, instead of having value-level identifiers. You could add tick marks to have multiple params of the same type, or make lower-case aliases. I thought it was a radical, but clever, idea. Also, Objective C kind of does named-only params, but isn't so hot for first-class functions
Open in Slack
PreviousNext
Powered by