Arc Forumnew | comments | leaders | submitlogin
2 points by rocketnia 5138 days ago | link | parent

Interestingly, it does seem like [currying] would work fine with keyword arguments.

Very interesting observation! XD It's inspiring....

Well, CSS has the slickest keyword argument API I've ever seen. The declaration "border: 2px solid black;" conveys the same information as a whole lot of other declarations like "border-top-width: 2px;", "border-bottom-style: solid;", etc. What if the "border" keyword were definable as a library?

  ; Haskellish syntax with liberties taken
  
  border width style color f = f -: border-width width
                                 -: border-style style
                                 -: border-color color
  
  border-width width f = f -: border-top-width width
                           -: border-bottom-width width
                           -: border-left-width width
                           -: border-right-width width
  
  Type Border-Top-Width  ; singleton type
  
  border-top-width value f = f -: keyword Border-Top-Width value
The premise behind -: is that it's a low-precedence left-associative binary operator such that (a -: b) is just (b a). (I don't know if Haskell has something like that already....)

The "keyword" function is axiomatic to the language. It takes a key value, a value to associate with it, and a function, and it returns the result of currying that function with that keyword information, overwriting the previous association for that key if necessary.

As for defining a function that does something with the keyword arguments it gets this way... I'm out of steam for now. What do you think?

EDIT: Hmm. With currying, we consider two-argument functions to be indistinguishable from functions that return functions, right? If a programmer naturally wants to write a two-argument function that takes keyword arguments, should that be a keyword-taking function that returns a plain function, a plain function that returns a keyword-taking function, or what? What about keyword-taking functions that naturally have zero arguments? Maybe currying and keyword arguments aren't very compatible after all, or maybe they just need a different evaluation model. (Maybe keywords should be dynamic variables observed using an "I'll consume this whole subspace of keywords, thanks" syntax?)