Re: [racket-users] Re: racket users fight for their right to colon keywords
I remember those classes as a student, to be honest I didn't really actually started to learn till after I'd left undergraduate. Don't get me wrong, I know how frustrating syntax/semantics nuances can be. I've been reflecting on the idea of existential keywords the past couple days and have realized that they complicate the situation more than their worth, so please consider this my formal withdrawal of support. I'm fine with just passing #t/#f to a keyword, it's crystal clear and consistent with everything else. In interest of peace, I offer you this tidbit; in the future if I ever send you code, I'll first run it through the clan-of-colons meta-language so you'll only see nice :keywords throughout the code. Aλexander On Monday, November 23, 2015 at 5:30:40 AM UTC-5, Neil Van Dyke wrote: > The Clan of Colon Keywords was willing to honor a truce. > > > I think for people coming from other languages with :keywords, Racket's > > #:keywords help to signal that they are not anything like how :keywords are > > usually used. > > I'm sure there are relatively better justifications for pound-colon than > signaling nuances to people in their first 10 seconds of being exposed > to a new language, than by encumbering the syntax for everyone, for all > time. After those first 10 seconds, you've had time to tell this > totally-new person from another language, "Racket keywords are somewhat > different from keywords in your other language (in a way that is not > worth pointing out at this early point, so sorry for the confusion, > please forget we even said anything, just assume for now that keywords > are similar to the keyword arguments you already know, because they are, > and let me tell you about the more important things for now)." > > (That said, in a particular kind of undergrad CS curriculum, in which > numerous languages are thrown at students, one language after another, > with students to be tested on language trivia, with little time to begin > to actually learn any of the languages in a meaningful way... then, > sure, teaching-to-the-test, one might make the subtly-different keyword > arguments appear different between two languages, to help prepare > students for the all-important test question, "How do keywords in Racket > differ from keywords in Common Lisp?" I shall not be complicit in that > atrocity. Fortunately, I'm not aware of anyone teaching Racket like that.) > > > I'd love to see existential/toggle keywords. > > Besides greatly changing how parsing could work (and complicating human > code reading of procedure applications, for the same reason that parsing > might have to do a lookup), imagine a common usage scenario... Procedure > A shares some of its signature with procedure B, and procedure A calls > B, passing some of its A's actual arguments to B. Compare the code for > "passing through" Boolean arguments using existential and > non-existential keywords, especially the combinatorial explosion (or > need for dynamic list apply) when more than one argument is Boolean. > > Neil V. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: racket users fight for their right to colon keywords
The Clan of Colon Keywords was willing to honor a truce. I think for people coming from other languages with :keywords, Racket's #:keywords help to signal that they are not anything like how :keywords are usually used. I'm sure there are relatively better justifications for pound-colon than signaling nuances to people in their first 10 seconds of being exposed to a new language, than by encumbering the syntax for everyone, for all time. After those first 10 seconds, you've had time to tell this totally-new person from another language, "Racket keywords are somewhat different from keywords in your other language (in a way that is not worth pointing out at this early point, so sorry for the confusion, please forget we even said anything, just assume for now that keywords are similar to the keyword arguments you already know, because they are, and let me tell you about the more important things for now)." (That said, in a particular kind of undergrad CS curriculum, in which numerous languages are thrown at students, one language after another, with students to be tested on language trivia, with little time to begin to actually learn any of the languages in a meaningful way... then, sure, teaching-to-the-test, one might make the subtly-different keyword arguments appear different between two languages, to help prepare students for the all-important test question, "How do keywords in Racket differ from keywords in Common Lisp?" I shall not be complicit in that atrocity. Fortunately, I'm not aware of anyone teaching Racket like that.) I'd love to see existential/toggle keywords. Besides greatly changing how parsing could work (and complicating human code reading of procedure applications, for the same reason that parsing might have to do a lookup), imagine a common usage scenario... Procedure A shares some of its signature with procedure B, and procedure A calls B, passing some of its A's actual arguments to B. Compare the code for "passing through" Boolean arguments using existential and non-existential keywords, especially the combinatorial explosion (or need for dynamic list apply) when more than one argument is Boolean. Neil V. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: racket users fight for their right to colon keywords
A fresh syntax wouldn't have to worry about breaking old code. I've written at least two variations on a new `defn` and/or `def` syntax [1][2]. I bet other people have, too. That topic could be its own long thread. It would probably include many good ideas. Of course it would probably become a "Racket 2" thread. :) Having written variations, have I used them extensively in code I've shared with other people? No. Why? Partly I think it goes to Neil's point about preferring a community consensus for basics. [1]: https://github.com/greghendershott/def-jambda [2]: https://github.com/greghendershott/defn -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: racket users fight for their right to colon keywords
On Monday, November 9, 2015 at 3:17:59 AM UTC, Neil Van Dyke wrote: > Note that, unlike some languages, I *don't* want `x` and `y` to be > optionally positional -- only keyworded. In my opinion, supplying a default value should make an argument implicitly keywordable. So (define (a b c (d 3) (e 4)) ...) would have 2 required positional arguments, and d and e could be present or omitted. If an argument has a default, it means it should be possible to omit it, and if you cannot specify keywords for the arguments after it (with defaults) then you cannot omit it. That leads to things like this: (define (foo a b (c #f) (d null) (e null))) (list a b c d e)) (let ((e '(1 2 3))) (list (foo 1 2 #f null e) (foo 1 2 #f null '(2 3 4)) (foo 1 2 #f e e) (foo 1 2 #f e))) Notice how in all cases the "optional" argument c had to be explicitly specified with its own default value. That is confusing because people can't tell if you mean "just ignore this and use the default" or "I really do think it important that c have this value." So, optional /non-keywordable/ arguments are a bad idea, in my opinion. Being able to do something like this is very important for clarity: (let ((e '(1 2 3))) (list (foo 1 2 :e e) (foo 1 2 :e '(2 3 4)) (foo 1 2 :d e :e e) (foo 1 2 :d e))) I don't have a real preference whether d and e should be allowed to be /positional/ though. It seems reasonable that it might be confusing to go (a 1 2 3 4) where either 3 or 4 are optional arguments with defaults if omitted. A case-lambda would be the best form if you really want (a 1 2) (a 1 2 3) and (a 1 2 3 4). But on the other hand, it doesn't seem too bad, as long as I have the option of specifying those optional arguments as keywords. But I don't have that option, because I have to say "#:keyword-argument (keyword-argument default)" or it doesn't /let/ me use a keyword to specify that argument's value. That leads to me being forced to boilerplate in defaults for intermediary optional variables. So, that's my big beef with the lambda/define syntax. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: racket users fight for their right to colon keywords
Nota Poin wrote on 11/08/2015 08:41 PM: What I want is implicit keyword names for arguments with defaults. So instead of: (define (foo #:bar? (bar? #f) #:foo (foo 42) #:some-variable-name (some-variable-name 3)) ...) I'd like a variation on this. Since I (and lots of existing Racket code) still use positional optional arguments sometimes, and since I'm not sure I *always* want arguments (regardless of whether optional) to have implicit keywords... I'd like simply a shorthand meaning "keyword argument derived from argument variable name". I haven't yet thought of a good backward-compatible syntax for this, but two non-ideal ideas: (define (bunny #(x) #(y) #(care-bears 1)) BODY ...) (define (bunny #f x #f y #f (care-bears 1)) BODY ...) Example uses: (bunny :x 1 :y 2) (bunny :x 3 :y 4 :care-bears 1000) Note that, unlike some languages, I *don't* want `x` and `y` to be optionally positional -- only keyworded. If I wanted positional arguments, they'd be *only* positional, and not optionally keyworded. Example: (define (pony x y #(unicorn? #true)) BODY ...) (pony 5 6) (pony 5 6 :unicorn? #false) (pony :x 7 8) ;=ERROR=> pony does not expect keyword argument `:x` (pony 5 6 #false) ;=ERROR=> pony expects 2 positional arguments, not 3 Neil V. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: racket users fight for their right to colon keywords
On Thu, Oct 22, 2015 at 8:09 PM, Andrew Gwozdziewycz wrote: > Surely there are books about this subject. Does anyone have any > recommendations for future self? This course has a module on voting theory: https://www.coursera.org/course/mathphil The course is not heavy-handed and can be taken even by people with a busy schedule. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: racket users fight for their right to colon keywords
On Thu, Oct 22, 2015 at 11:01 AM, Jack Firth wrote: > Perhaps it would have been better phrased as "Which do you prefer, > #:keyword or :keyword?" with options like "strongly prefer x", "prefer x", > "indifferent", "prefer y", "strongly prefer y", rather than two different > 1-10 scales. > While I agree that this might have been better, I've never, prepared a survey before where the questions were perfect, and I didn't think of some optimization *after the fact* about how to phrase them better, or get better data. Surely there are books about this subject. Does anyone have any recommendations for future self? > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- http://www.apgwoz.com -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
