Re: [racket-users] Re: racket users fight for their right to colon keywords

[Alexander McLin]

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

[Neil Van Dyke]

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.

[racket-users] Re: racket users fight for their right to colon keywords

[Alexander McLin]

Upon some reflection, I realized that the existential proposal as outlined in 
my earlier reply introduces an ambiguity into the keyword system. Since 
keywords can be used in any position relative to any actual positional 
arguments, there'd be no way to distinguish an existential keyword followed by 
a positional argument from an existential keyword followed by a value intended 
to be passed to that keyword.

So either the proposal is amended to disallow any values being passed to an 
existential keyword or just drop the idea. I admit I feel uneasy about allowing 
a special boolean case in the keyword grammar when all other keyword cases are 
allowed to assume arbitrary values.


Aλexander


On Sunday, November 22, 2015 at 12:08:49 PM UTC-5, Alexander McLin wrote:
> I don't really have a horse in this race. My position is very similar to 
> Alexis which is why I didn't vote in the poll too. When I first arrived to 
> Racket the #: syntax made me go "what in the world?" Since then I've grown to 
> appreciate the reasoning behind the deliberate eye catching keyword syntax. 
> 
> I appreciate that Racket takes a principled approach to making language 
> concepts precise and avoid muddling together distinct purposes as many other 
> languages do. Racket keywords are just that, syntactic tags denoting function 
> application arguments no more no less. 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.
> 
> Honestly I think that an alternative keyword syntax should not be in the base 
> language, the ship has already long since sailed and it would be a mistake to 
> try to reverse course and fix it for sake of aesthetics. Racket already uses 
> # to suggest syntax specialness, like #t, #f, #', #(), #<>, #lang. To me, #: 
> seems to naturally fit into that category.
> 
> It would be far better to put the alternative in a meta-language that people 
> can choose to use or not. Concerns about snippets containing :keywords posted 
> to social media and elsewhere leading to confusion also apply equally to 
> snippets of other non-base languages. I've seen several cases of scribble and 
> other snippets being posted without #lang supplied and if I tried blindly 
> running them directly in Racket, I'd get errors. If anything this should 
> remind us that providing #lang is mandatory, not optional and adjust our 
> habits to be more careful in the future when posting to social media.
> 
> Now that's been said, I'm with gneuner2. I'd love to see existential/toggle 
> keywords.
> 
> If I may tweak his proposal a bit, something like 
> 
> (define (foo #:keyword (id)) (if (id) 'foo 'bar))
> 
> Basically if an identifier just by itself is given in the list immediately 
> following the keyword, then it's treated as boolean. When keyword is supplied 
> in a function call, then id evaluates to #t otherwise it's #f. If someone 
> provides a value with the keyword - which does not presents an issue - id 
> will be bound to that value which will still be treated as truthy, unless the 
> value happens to be #f.
> 
> So based off the grammar from Racket Reference for define 
> http://docs.racket-lang.org/reference/define.html
> 
> We'd be adding another clause to the arg production rule.
> 
> arg   =   arg-id
>   |   [arg-id default-expr]
>   |   keyword arg-id
> |   keyword [arg-id]
>   |   keyword [arg-id default-expr]
> 
> 
> Aλexander
> 
> 
> 
> On Saturday, November 21, 2015 at 6:06:58 PM UTC-5, gneuner2 wrote:
> > Coming late to this.
> > 
> > On Wed, 14 Oct 2015 11:50:41 -0400, Neil Van Dyke
> >  wrote:
> > 
> > >We are conducting a highly scientific poll.
> > >
> > >The question we want to answer is whether people would like for the 
> > >Racket standard languages to have symbols that begin with the colon 
> > >character (except for the symbol `:`) to read the same has keywords that 
> > >begin with pound-colon.
> > 
> > I actually prefer the #: syntax, but what I would like is support for
> > "existence" keywords - i.e. keywords with no argument - where the only
> > thing you care about is whether or not the keyword was provided.
> > 
> > Obviously, this can be done using a "rest" argument and symbols, but
> > the #: syntax draws attention that other symbols do not because
> > DrRacket, at least by default, colors keywords differently from other
> > symbols.
> > 
> > Although the keyword syntax coloring still works with a tick before a
> > symbol that looks like a keyword, having to remember the tick is a
> > PITA when you are thinking of the symbol as a keyword.  If you forget
> > it, you get a  nasty
> > "application: missing argument expression after keyword"
> > error.
> > 
> > 
> > How much trouble would it cause to allow naked keywords and provide a
> > 

[racket-users] Re: racket users fight for their right to colon keywords

[Alexander McLin]

I don't really have a horse in this race. My position is very similar to Alexis 
which is why I didn't vote in the poll too. When I first arrived to Racket the 
#: syntax made me go "what in the world?" Since then I've grown to appreciate 
the reasoning behind the deliberate eye catching keyword syntax. 

I appreciate that Racket takes a principled approach to making language 
concepts precise and avoid muddling together distinct purposes as many other 
languages do. Racket keywords are just that, syntactic tags denoting function 
application arguments no more no less. 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.

Honestly I think that an alternative keyword syntax should not be in the base 
language, the ship has already long since sailed and it would be a mistake to 
try to reverse course and fix it for sake of aesthetics. Racket already uses # 
to suggest syntax specialness, like #t, #f, #', #(), #<>, #lang. To me, #: 
seems to naturally fit into that category.

It would be far better to put the alternative in a meta-language that people 
can choose to use or not. Concerns about snippets containing :keywords posted 
to social media and elsewhere leading to confusion also apply equally to 
snippets of other non-base languages. I've seen several cases of scribble and 
other snippets being posted without #lang supplied and if I tried blindly 
running them directly in Racket, I'd get errors. If anything this should remind 
us that providing #lang is mandatory, not optional and adjust our habits to be 
more careful in the future when posting to social media.

Now that's been said, I'm with gneuner2. I'd love to see existential/toggle 
keywords.

If I may tweak his proposal a bit, something like 

(define (foo #:keyword (id)) (if (id) 'foo 'bar))

Basically if an identifier just by itself is given in the list immediately 
following the keyword, then it's treated as boolean. When keyword is supplied 
in a function call, then id evaluates to #t otherwise it's #f. If someone 
provides a value with the keyword - which does not presents an issue - id will 
be bound to that value which will still be treated as truthy, unless the value 
happens to be #f.

So based off the grammar from Racket Reference for define 
http://docs.racket-lang.org/reference/define.html

We'd be adding another clause to the arg production rule.

arg =   arg-id
|   [arg-id default-expr]
|   keyword arg-id
|   keyword [arg-id]
|   keyword [arg-id default-expr]


Aλexander



On Saturday, November 21, 2015 at 6:06:58 PM UTC-5, gneuner2 wrote:
> Coming late to this.
> 
> On Wed, 14 Oct 2015 11:50:41 -0400, Neil Van Dyke
>  wrote:
> 
> >We are conducting a highly scientific poll.
> >
> >The question we want to answer is whether people would like for the 
> >Racket standard languages to have symbols that begin with the colon 
> >character (except for the symbol `:`) to read the same has keywords that 
> >begin with pound-colon.
> 
> I actually prefer the #: syntax, but what I would like is support for
> "existence" keywords - i.e. keywords with no argument - where the only
> thing you care about is whether or not the keyword was provided.
> 
> Obviously, this can be done using a "rest" argument and symbols, but
> the #: syntax draws attention that other symbols do not because
> DrRacket, at least by default, colors keywords differently from other
> symbols.
> 
> Although the keyword syntax coloring still works with a tick before a
> symbol that looks like a keyword, having to remember the tick is a
> PITA when you are thinking of the symbol as a keyword.  If you forget
> it, you get a  nasty
> "application: missing argument expression after keyword"
> error.
> 
> 
> How much trouble would it cause to allow naked keywords and provide a
> predicate based on their name?  E.g.,
> 
> (define ( test blah #:opt #:req req )
>:
>   (when #:opt?  ... )
>:
>   )
> 
> (test #:req 3)
> (test #:req 42 #:opt)
> 
> Or even something like  (define ( test blah #:opt [] #:req req ) which
> makes it more obvious that the keyword is only there to be tested?
> 
> George

-- 
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.

[racket-users] Re: racket users fight for their right to colon keywords

[George Neuner]

Coming late to this.

On Wed, 14 Oct 2015 11:50:41 -0400, Neil Van Dyke
 wrote:

>We are conducting a highly scientific poll.
>
>The question we want to answer is whether people would like for the 
>Racket standard languages to have symbols that begin with the colon 
>character (except for the symbol `:`) to read the same has keywords that 
>begin with pound-colon.

I actually prefer the #: syntax, but what I would like is support for
"existence" keywords - i.e. keywords with no argument - where the only
thing you care about is whether or not the keyword was provided.

Obviously, this can be done using a "rest" argument and symbols, but
the #: syntax draws attention that other symbols do not because
DrRacket, at least by default, colors keywords differently from other
symbols.

Although the keyword syntax coloring still works with a tick before a
symbol that looks like a keyword, having to remember the tick is a
PITA when you are thinking of the symbol as a keyword.  If you forget
it, you get a  nasty
"application: missing argument expression after keyword"
error.


How much trouble would it cause to allow naked keywords and provide a
predicate based on their name?  E.g.,

(define ( test blah #:opt #:req req )
   :
  (when #:opt?  ... )
   :
  )

(test #:req 3)
(test #:req 42 #:opt)

Or even something like  (define ( test blah #:opt [] #:req req ) which
makes it more obvious that the keyword is only there to be tested?

George

-- 
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

[Greg Hendershott]

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

[Neil Van Dyke]

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

[Nota Poin]

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

[Pierpaolo Bernardi]

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.

[racket-users] Re: racket users fight for their right to colon keywords

[Jack Firth]

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.

-- 
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

[Andrew Gwozdziewycz]

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.