racket users fight for their right to colon keywords

[Neil Van Dyke]

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.

That is, when this glorious colon-keywords support is added, instead of
having to type and look at:

(foo #:abc 1 #:xyx 42)

you can choose to bask in the beauty of:

(foo :abc 1 :xyx 42)

Then you would be free to use the gorgeous colon-keywords everywhere in
Racket, including in quick one-line examples in email list posts.

All people of great aesthetic sense, intellect, and good moral fiber,
who would naturally like everyone to have the right to use either
colon-keywords or (eww) pound-colon keywords (in unity, and without
unnecessary `#lang` schisms!), should answer the quick poll:

http://goo.gl/forms/Kwl3uZVMsb

(When the poll question asks "Is it worth changing?", read it is as "You
are a good person, and you naturally think Racket should support both
colon-keywords and pound-colon keywords, right?")

I call upon all freedom-loving Racketeers to stand up and fight for the
righteous cause of colon-keywords. The moment to answer this highly
scientific poll is now.

Neil V.

[Jukka Tuominen]

Yoda like that would, but to me it looks backwards. How about...?
key: value

br, jukka
UX Manager :)

Sent from my iPhone

> --
> 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...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jay McCarthy]

I briefly considered including Objective-C/Smalltalk style keywords in
the form too. I haven't extensively programmed with them, but I find
them kind of beautiful.

Jay

--
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

"Wherefore, be not weary in well-doing,
for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
- D&C 64:33

[Neil Van Dyke]

I find `keyword:` kinda pretty, too (I first used them in Smalltalk,
though Smalltalk syntax takes it a huge step further).

But, IIRC, it was Joe Marshall who pointed out (one of the past times
keywords were discussed) that `:keyword`s are visually less ambiguous in
Lisp syntax when use of a form with multiple keyword arguments is split
across multiple lines.

That point moved me back to the tried-and-true Lisp `:keyword`, at least
for Lisp code.

Neil V.

[Martin DeMello]

Chicken scheme has an option for that: http://wiki.call-cc.org/man/4/Non-standard%20read%20syntax#keyword

I'm a fan; it makes the code pretty pleasant to read.

martin

[Alex Knauth]

Racket has an option for that. It's a meta-language that I made this morning.

#lang colon-kw racket

You can use it for one or two files without messing up everything else. 

[Alex Knauth]

You can use

#lang colon-kw racket

for :kw syntax, and

#lang kw-colon racket

for kw: syntax.

They are compose-able as well, so you can use

#lang colon-kw kw-colon racket

to let :kw and kw: both work in the same file.

[Neil Van Dyke]

Alex Knauth wrote on 10/14/2015 04:37 PM:
> You can use
> #lang colon-kw racket
> for :kw syntax, and
> #lang kw-colon racket
> for kw: syntax.

If the standard `#lang racket` and `#lang racket/base` don't support
`:keyword` out of the box -- but instead some alternative reader or
forked #lang is required -- then we would expect error messages about
`:keyword` not working to be an FAQ on the email list. That's one
intuitive example of the kinds of problems that arise.

Code snippets get detached from `#lang` lines all the time, especially
in sometimes-terse 'social media' like email, chat, blogs, Twitter, etc.

I know Racket (I think it was still PLT Scheme then) had its reasons for
introducing an unconventional keyword syntax at the time, and I've
therefore tried years of pound-colon (with great discomfort in the
rear), but pound-colon still hasn't grown on me. I'm very ready for the
conventional colon-keyword syntax to also be supported in `#lang racket`
and `#lang racket/base`.

I very much appreciate diligence about backward-compatibility, but I'm
not actually aware of any Racket code that actually uses colon-symbol
for any purpose other than as a keyword. And the ones that use
colon-symbol as makeshift keywords are few and far between, and only for
historical reasons, from before PLT Scheme had keywords. (Or from some
obscure super-portable R5RS Scheme SRFI, again because R5RS Scheme
didn't have keywords, and they were just improvising keywords by using
symbols in the conventional way, i.e., `:keyword`.)

Neil V.

[Alex Knauth]

On Oct 14, 2015, at 5:34 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:

I very much appreciate diligence about backward-compatibility, but I'm not actually aware of any Racket code that actually uses colon-symbol for any purpose other than as a keyword.  And the ones that use colon-symbol as makeshift keywords are few and far between, and only for historical reasons, from before PLT Scheme had keywords.  (Or from some obscure super-portable R5RS Scheme SRFI, again because R5RS Scheme didn't have keywords, and they were just improvising keywords by using symbols in the conventional way, i.e., `:keyword`.)

Have you seen syntax-parse?

Jens Axel already mentioned (require (prefix-in : parser-tools/lex-sre) on the dev list.

There's also :print-type expr, :type, :query-type/args, and :query-type/result from typed racket.

And also, searching : in the package docs gives me this:

http://pkg-build.racket-lang.org/doc/search/index.html?q=%3A

It's not worth changing the default for all of racket just to avoid putting #lang colon-kw racket at the top of a program. 

[Neil Van Dyke]

Alex Knauth wrote on 10/14/2015 05:57 PM:
>
>> On Oct 14, 2015, at 5:34 PM, Neil Van Dyke <ne...@neilvandyke.org

>> <mailto:ne...@neilvandyke.org>> wrote:
>
>> I very much appreciate diligence about backward-compatibility, but
>> I'm not actually aware of any Racket code that actually uses
>> colon-symbol for any purpose other than as a keyword. And the ones
>> that use colon-symbol as makeshift keywords are few and far between,
>> and only for historical reasons, from before PLT Scheme had keywords.
>> (Or from some obscure super-portable R5RS Scheme SRFI, again because
>> R5RS Scheme didn't have keywords, and they were just improvising
>> keywords by using symbols in the conventional way, i.e., `:keyword`.)
>
> Have you seen syntax-parse?

Yes, `syntax-parse` is probably my favorite modern addition to Racket,
ever. Why are colon-keywords a problem?

> Jens Axel already mentioned (require (prefix-in:parser-tools/lex-sre)
> on the dev list.
> There's also :print-type expr, :type, :query-type/args, and
> :query-type/result from typed racket.

Those are two unfortunate things, and potentially showstoppers. I think
the convention of colon-keywords in Lisps, even in Scheme dialects,
predates both of those. But possession is nine-tenths of the law, so I
agree that these would have to be looked at and addressed.

> And also, searching : in the package docs gives me this:
> http://pkg-build.racket-lang.org/doc/search/index.html?q=%3A

> <http://pkg-build.racket-lang.org/doc/search/index.html?q=:>

Except for some cryptic-looking non-idiomatic identifiers in
`math/array`, I don't see a problem in that search. (Even the liberties
of `math/array` could even be accommodated, if keywords are made
something like `^:[a-zA-Z].*$`. And the `srfi/42` ones are the main
example I had in mind when I said before, about SRFIs and improvised
keywords.)

>
> It's not worth changing the default for all of racket just to avoid
> putting #lang colon-kw racket at the top of a program.
>

I currently have the opposite opinion on that point.

Partly because, before I would use `#lang colon-kw racket/base` at the
top of each of my modules, I would use `#lang paddle/base`. Then the
effective forking of the language is perhaps more apparent, even though
the actual texts below the respective differing `#lang` lines would be
identical in both cases. Because I really-really don't want to
effectively fork the Racket dialect in which people write snippets on
email lists and such, that's why I'm investing in the energy-intensive
town hall dialogue that's usually involved in making any programming
language change when it's not simply done by fiat and announced as a
done deal. :)

Neil V.

[Daniel Prager]

Something for consideration in Racket 2?

I've gotten used #:keywords, but initially felt that they were inelegant.

Dan

[Jack Firth]

It's not "forking the language", it's turning into an opt-in library. The huge difference between the colon-kw language mixin and that paddle/base language is that the form isn't a language. It can be provided to any language. If your paddle/base language didn't provide colon keywords, you could just as easily get them with #lang colon-kw paddle/base. You're not forking anything, you're simply using a library.

I find the idea of breaking existing code for such a simple stylistic matter that you can fix with nine extra characters at the top of your file somewhat absurd. This isn't fixing some troublesome misfeature, or adding an important new base language feature, or correcting buggy behavior, it's tweaking a completely superficial minor behavior for aesthetic benefit that's quite opinion-driven and not at all a benefit for even a majority of Racket programmers. That's the kind of thing that belongs precisely in an opt-in library, not in a breaking change of the core language.

[Robby Findler]

I love this message. Highlight of my day. :)

[Alexis King]

> It's not "forking the language", it's turning into an opt-in library. The huge difference between the colon-kw language mixin and that paddle/base language is that the form isn't a language. It can be provided to any language. If your paddle/base language didn't provide colon keywords, you could just as easily get them with #lang colon-kw paddle/base. You're not forking anything, you're simply using a library.

I can’t wait until all of my programs look like this at the top:

#lang at-exp colon-kw curly-fn debug exact-decimal postfix-dot-notation sweet-exp racket/base

Okay, so that is perhaps a straw man, but I think the point still stands. I am a strong supporter of meta-languages, but I am a stronger supporter of standardization. I remain ambivalent about this particular issue—I think there are good arguments on both sides—but consider this to be me playing devil’s advocate.

[Benjamin Greenman]

On Wed, Oct 14, 2015 at 11:01 PM, Alexis King <lexi....@gmail.com> wrote:

I can’t wait until all of my programs look like this at the top:

Haskellers are living the dream. For example:

https://github.com/ekmett/lens/blob/master/src/Control/Lens/Tuple.hs

[Pierpaolo Bernardi]

On Wed, Oct 14, 2015 at 11:34 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:
> Alex Knauth wrote on 10/14/2015 04:37 PM:
>>
>> You can use
>> #lang colon-kw racket
>> for :kw syntax, and
>> #lang kw-colon racket
>> for kw: syntax.
>
>
> If the standard `#lang racket` and `#lang racket/base` don't support
> `:keyword` out of the box -- but instead some alternative reader or forked
> #lang is required -- then we would expect error messages about `:keyword`
> not working to be an FAQ on the email list. That's one intuitive example of
> the kinds of problems that arise.

But supporting this out of the box in #lang racket would invalidate
existing racket programs, no?

That's another example :)

[Deren Dohoda]

I don't have a very strong opinion, it seems like convenient syntax, but half of what draws me to stick with lisps is the low amount of syntax. Pound-colon has a strong line noise quality to it which colons lack,  I admit. But they also have an explicit feel which colons lack.

Inclusion or exclusion of this will not really affect me though. I will probably stick to pound-colon.

Deren

[Laurent]

On Thu, Oct 15, 2015 at 3:25 PM, Deren Dohoda <deren....@gmail.com> wrote:

I don't have a very strong opinion, it seems like convenient syntax, but half of what draws me to stick with lisps is the low amount of syntax. Pound-colon has a strong line noise quality to it which colons lack,  I admit. But they also have an explicit feel which colons lack.

In particular, they have a "reader syntax" feeling, as most things that start with a pound in Racket. I initially didn't like them for keywords, but now I'm feeling somewhat ok with them. Having two characters to prefix a keyword argument is a lot though, especially when one uses them so much.

Laurent

[Hendrik Boom]

I'd like to ask:

What do the Scheme standards say about this?
What do Lisp standards say about this?

I don't know the answers to these questons, though maybe I should, and
Racket is not a standard Scheme, but I think these answers should
at least guide us.

-- hendrik

[Anthony Carrico]

I didn't really want to get dragged into this, but keep in mind that:

(symbol? #'test) ; -> #f

IIRC the common lisp keywords you admire are symbols. I think that the
proposed syntax confuses symbols and keywords, which are distinct types.

--
Anthony Carrico

[Anthony Carrico]

On 10/15/2015 03:37 PM, Anthony Carrico wrote:
> I didn't really want to get dragged into this, but keep in mind that:
>
> (symbol? #'test) ; -> #f

err... (symbol? '#:test) ; -> #f

--
Anthony Carrico

[Anthony Carrico]

On 10/15/2015 03:39 PM, Anthony Carrico wrote:
> On 10/15/2015 03:37 PM, Anthony Carrico wrote:
>> I didn't really want to get dragged into this, but keep in mind that:
>>
>> (symbol? #'test) ; -> #f
>
> err... (symbol? '#:test) ; -> #f
>

Yes. I found this in the Common Lisp Hyperspec:

(symbolp :test) => true

http://www.lispworks.com/documentation/HyperSpec/Body/f_symbol.htm#symbolp

--
Anthony Carrico

[Anthony Carrico]

In case I'm being to oblique, I'm trying to point out that:
(equal? '#:test ':test) ; -> #f
which means that the proposal will certainly break things.

--
Anthony Carrico

[Neil Van Dyke]

Hendrik Boom wrote on 10/15/2015 01:25 PM:
> I'd like to ask:
>
> What do the Scheme standards say about this?
> What do Lisp standards say about this?
>
> I don't know the answers to these questons, though maybe I should, and
> Racket is not a standard Scheme, but I think these answers should
> at least guide us.

Racket is all grown-up as its own language/platform now, and I
definitely wouldn't encumber Racket evolution with CL or RnRS
decisions. (Though those other Lisp family subtrees have their own
noble merits.)

I just found a paper that lays out Racket's pound-colon-prefix
rationale: Flatt, Barzilay, "Keyword and Optional Arguments in PLT
Scheme", http://www.ccs.neu.edu/racket/pubs/scheme2009-fb.pdf

But to start to answer your question, CL has long used colon-prefix for
the visual appearance of keyword arguments.

Most Schemes don't agree with each other on keywords, though there is a
tendency towards programmer-controlled selectivity among multiple
conventions for what keyword arguments look like:
* I don't see keyword arguments in a quick skim of R7RS (although Google
does find random claims that R7RS has keyword arguments, perhaps
referring to committee discussion).
* Gambit Scheme has colon-suffix, plus some selectivity for colon-prefix
(and uses pound-bang for some different purpose?).
http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Keyword-syntax
* Marc Feeley's (of Gambit fame) SRFI-88 and SRFI-89 propose colon-suffix.
* Guile supports all three conventions, selectively.
http://www.gnu.org/software/guile/manual/html_node/Keyword-Read-Syntax.html
* Chicken uses pound-bang and selectively either colon-prefix or
colon-suffix.
http://wiki.call-cc.org/man/4/Non-standard%20read%20syntax#keyword
* Gauche has colon-prefix.
http://practical-scheme.net/gauche/man/gauche-refe_5.html
* Chibi Scheme seems to use colon-suffix.

The Scheme situation is discouraging, and I'm glad that Racket (PLT
Scheme) went ahead and did something. However, I wish we all had cared
slightly less about R5RS compatibility and such back then (especially
since R5RS compatibility has been abandoned in much larger ways in
Racket today, such as in pair mutability). Perhaps I could've been
using colon-prefix happily the last several years. And also, no one
would have introduced the few problematic colon-symbols that now have to
be considered before adding colon-prefix keywords today.

I'm still interested in adding colon-prefix keywords to `#lang racket`
and `#lang racket/base`, ASAP, if the designers consider that
worthwhile. If it's not considered worthwhile at this time, then I'm
tempted to finally do it with a package of my own writing, though that
might effectively fragment the language.

(BTW, in response to an earlier comment regarding fragmentation, I think
that `#lang foo-reader racket` and `#lang foo-replacing-racket-reader`
are equivalent in immediate fragmentation effect. What's more
significant to fragmentation is when different people are using
*incompatible source dialects* in snippets of code in forum posts,
documentation, etc. -- not what the `#lang` line looks like in a
complete module, if the code below that line would be the same
regardless, and the module still interoperates across source dialects.)

Neil V.

[Matthias Felleisen]

On Oct 15, 2015, at 5:01 PM, Neil Van Dyke <ne...@neilvandyke.org> wrote:

> BTW, in response to an earlier comment regarding fragmentation, I think that `#lang foo-reader racket` and `#lang foo-replacing-racket-reader` are equivalent in immediate fragmentation effect. What's more significant to fragmentation is when different people are using *incompatible source dialects* in snippets of code in forum posts, documentation, etc. -- not what the `#lang` line looks like in a complete module, if the code below that line would be the same regardless, and the module still interoperates across source dialects.

Neil and everyone else,

Communities around extensible languages naturally fragment. The very moment you provide a mini-linguist, which is what a programmer really is, with the means to define nouns and verbs, the fragmentation starts. A common reason for fragmentation is the creation and use of function libraries. For example, a Fortran programmer in the field of physical simulations used different function libraries than one in commercial check processing. When the former read the code of the latter, he invariably experienced some form of alienation. [I am using past tense because I am sure Fortran is kind of dead now :-).]

When you allow programmers to define even more advanced aspects of a language -- with means such as macros -- you get even more fragmentation. People wish to conduct a discourse about a domain in the language of their domain, and the more we enable the creation of languages, the closer to the domain language(s) we get.

In the end though, all of these linguistic disconnects can be bridged with a bit of reading code and documentation.

In contrast to linguistic fragmentation, programming language communities may also experience social fragmentation. At the simplest level, they may disagree on the meaning of some feature. I think the order of evaluation in a function application is an example of the right kind here. They may disagree with the philosophy of language design in the standardization sense. The rollback of R6RS to the quasi-R5RS standard of R7RS is an example of this kind. This technical disagreements lead to forks in the tree of language development that are much more serious than the linguistic differentiation above.

My take is that #lang colon-kw-mixn racket/base is a dialect in the way South German or Swiss German relates to High German (a normative language that nobody speaks except for some pretty-looking dumb TV announcers perhaps). The R6RS vs R7RS differentiation of Scheme vs Clojure separation is more like English and German.

With this said, I am fine with North Germans. I just wished they learned to speak properly -- Matthias :-)

p.s. Similar analogies could be drawn with American social dialects. But as a Man from Away, I'll stay away from this hot topic.

[Eli Barzilay]

Yes, CL keywords are symbols, but there's no confusion since they are
very different from regular symbols.

To complete the details for whoever might be interested, in CL symbols
can be written as `foo:bar` for the (externally visible) "bar" symbol
from the "foo" package. Symbols with no colon are implicitly in the
current package. This is why `:foo` makes sense for keywords: it's the
"foo" symbol from the special keyword package -- special since it has no
name, and since all of its symbols are visible outside. Now, consider
the fact that CL equates "identifiers" with "symbols", and uses packages
as a half-assed[*] attempt to get some sanity with my code not stepping
over your code -- and that should explain why `:foo` and `foo` are both
"the same type" but are very different in nature -- to the point that
your argument of a distinct type doesn't hold well in CL (and in Racket
too, since Neil's suggestion would make `:foo` not be a symbol).

Notes:

1. I use [*] in a technical way -- I once tried to explain hygiene to
CLers by saying that it's as if each scope has its own (anonymous)
package.

2. Also, talking about what counts as a symbol in CL is not too
productive. CL can surprise you with gems like: (symbol? (cdr '(1)))
returning true.

3. I didn't see it mentioned so: the original motivation for `#:foo` was
an attempt to avoid the argument of `:foo` vs `foo:` vs "either one"
vs whatever.

--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!

[Hendrik Boom]

On Thu, Oct 15, 2015 at 05:18:22PM -0400, Matthias Felleisen wrote:
...
...

> A common reason for fragmentation is the creation and use of function
> libraries. For example, a Fortran programmer in the field of physical
> simulations used different function libraries than one in commercial
> check processing. When the former read the code of the latter, he
> invariably experienced some form of alienation. [I am using past tense
> because I am sure Fortran is kind of dead now :-).]

No, Fortran is not dead. It's he preferred language used in heavy
numerical computation because of its extreme efficiency for this class
of application.

See
http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/

Fun that you mentioned Fortran; the article contains the sentence
"Originally specified in 1958, Lisp is the second-oldest high-level
programming language in widespread use today; only Fortran is older"

credited to Dr. Joey Paquet.

-- hendrik

[Neil Van Dyke]

Regarding Fortran, about 3 weeks ago, I looked into implementing a
`#lang fortran77` or `#lang fortran90`.

Functionality-wise, it looks doable; speed-wise, not so great. I have
no further need for this, but it's an interesting practical/hobby
project someone might want to pursue.

(For easy intermixing of Fortran and Racket code, there are boxing and
marshalling inefficiencies, especially when you combine that with code
that depends on behavior like shared mutations of very
byte/word-layout-sensitive overlaying/sharing of dissimilar types on the
same memory. Though there do appear to be lots of optimization
opportunities, when you can prove that some Fortran-specific language
complications don't apply, to particular
procedures/variables/values/calls. The control flow construct mapping
is relatively easy. F77 and F90 parsing are both doable, and
potentially a little fun. I didn't get all the way into all the things
that can be done with arrays, and there might be other tricky Fortran
features I didn't get to. It would be a substantial project, for either
a good practical reason or a hobby.)

Neil V.

[Konrad Hinsen]

Matthias Felleisen writes:

> [I am using past tense because I am sure Fortran is kind of dead
> now :-).]

There are probably more active Fortran programmers than active Racket
programmers at this time.

> People wish to conduct a discourse about a domain in the language
> of their domain, and the more we enable the creation of languages,
> the closer to the domain language(s) we get.
>
> In the end though, all of these linguistic disconnects can be
> bridged with a bit of reading code and documentation.

Exactly, just like for human languages. An added condition for
programming languages is interoperability: I am fine with reading
someone else's code in a different dialect, but I certainly do not
want to rewrite it in my own dialect just to be able to use it.

For me the strongest point of Racket is that it encourages linguistic
diversity while maintaining (nearly enforcing) interoperability. My
dream language environment would go one step further and provide a
second more low-level interoperability layer for performance-oriented
dialects (C/Fortran style).

Konrad.

[Matthias Felleisen]

[ message quoted in reversed for obvious reasons ]


On Oct 16, 2015, at 7:18 AM, Konrad Hinsen <konrad...@fastmail.net> wrote:

> Matthias Felleisen writes:
>> People wish to conduct a discourse about a domain in the language
>> of their domain, and the more we enable the creation of languages,
>> the closer to the domain language(s) we get.
>>
>> In the end though, all of these linguistic disconnects can be
>> bridged with a bit of reading code and documentation.
>
> Exactly, just like for human languages. An added condition for
> programming languages is interoperability: I am fine with reading
> someone else's code in a different dialect, but I certainly do not
> want to rewrite it in my own dialect just to be able to use it.
>
> For me the strongest point of Racket is that it encourages linguistic
> diversity while maintaining (nearly enforcing) interoperability. My
> dream language environment would go one step further and provide a
> second more low-level interoperability layer for performance-oriented
> dialects (C/Fortran style).

Does the existing FFI provide you with enough efficiency when needed?

;; ------------------------------------------------------------

Onward, to the fun part.

>> [I am using past tense because I am sure Fortran is kind of dead
>> now :-).]
>
> There are probably more active Fortran programmers than active Racket
> programmers at this time.

If that's all you guys can come up with (ref to Fortran article),
then I am removing the brackets from my original message and apologize
for beating a dead horse. Even Fortran doesn't deserve this.



-- Matthias

[Matthias Felleisen]

This would indeed fit into the "full spectrum" part of the Racket "stack" as presented in the manifesto and especially the presentation as given at (fifth RacketCon).

-- Matthias

[Greg Hendershott]

> Code snippets get detached from `#lang` lines all the time, especially in
> sometimes-terse 'social media' like email, chat, blogs, Twitter, etc.

Although this can be a problem, I think it's already a problem in
Racket -- and generally.

Example: Spend time answering a Racket question on Stack Overflow.
Discover it's N/A because they didn't mention they're using `#lang
bsl`. /headdesk. Although often there are clues in the code itself --
or in meta-data like the date or the user's rep -- sometimes you just
can't tell.

But even without `#lang`, there's the plain old way this can be a
problem. Let's say `#lang racket/base` does add `:keywords` in 7.1, as
you want. Hooray! You post a code snippet using them. I try it with
7.0. Boo!

Non-trivial code snippets have assumptions. The `#lang` line is
actually a way for people to supply some of that explicitly in code --
which is good. (Of course, regardless of whether they can do so using
#lang or prose, people will forget to include information on teh
interwebs. I am currently working hard to solve this problem
generally.)

[Konrad Hinsen]

Matthias Felleisen writes:

> > For me the strongest point of Racket is that it encourages linguistic
> > diversity while maintaining (nearly enforcing) interoperability. My
> > dream language environment would go one step further and provide a
> > second more low-level interoperability layer for performance-oriented
> > dialects (C/Fortran style).
>
>
> Does the existing FFI provide you with enough efficiency when needed?

Yes, but I have to write C code outside of Racket. I'd like to be able
to define a #lang in Racket that operates at the level of C
(i.e. machine-level data types, no GC, etc.), and I'd like to generate
specialized code in that low-level language from my standard Racket
code.

Lush (http://lush.sourceforge.net/) has something like that but it
seems kind of dead now. A while ago I saw the annoucement for a new
language called Terra (http://terralang.org/) that is a low-level
complement to Lua, but I haven't taken a closer look yet.

Konrad.

[Matthias Felleisen]

On Oct 16, 2015, at 9:24 AM, Konrad Hinsen <konrad...@fastmail.net> wrote:

> Matthias Felleisen writes:
>
>>> For me the strongest point of Racket is that it encourages linguistic
>>> diversity while maintaining (nearly enforcing) interoperability. My
>>> dream language environment would go one step further and provide a
>>> second more low-level interoperability layer for performance-oriented
>>> dialects (C/Fortran style).
>>
>>
>> Does the existing FFI provide you with enough efficiency when needed?
>
> Yes, but I have to write C code outside of Racket. I'd like to be able
> to define a #lang in Racket that operates at the level of C
> (i.e. machine-level data types, no GC, etc.), and I'd like to generate
> specialized code in that low-level language from my standard Racket
> code.

Yes, we want to get there. See "full spectrum language" in other reply.

> Lush (http://lush.sourceforge.net/) has something like that but it
> seems kind of dead now. A while ago I saw the annoucement for a new
> language called Terra (http://terralang.org/) that is a low-level
> complement to Lua, but I haven't taken a closer look yet.

Thanks

[William G Hatch]

On Fri, Oct 16, 2015 at 03:24:06PM +0200, Konrad Hinsen wrote:
>Matthias Felleisen writes:
>
> > > For me the strongest point of Racket is that it encourages linguistic
> > > diversity while maintaining (nearly enforcing) interoperability. My
> > > dream language environment would go one step further and provide a
> > > second more low-level interoperability layer for performance-oriented
> > > dialects (C/Fortran style).
> >
> >
> > Does the existing FFI provide you with enough efficiency when needed?
>
>Yes, but I have to write C code outside of Racket. I'd like to be able
>to define a #lang in Racket that operates at the level of C
>(i.e. machine-level data types, no GC, etc.), and I'd like to generate
>specialized code in that low-level language from my standard Racket
>code.

FYI, I'm a grad student at Utah with Matthew, and my current project
is a #lang pre-racket that compiles to C. It hasn't really gotten off
the ground yet because I've been busy with classes and fellowship
applications, but in the relatively near future we should have this.

William

P.S. On the point of keywords, I think having #lang colon-kw <lang> is
the right approach. If people worry about living the dream of Haskell's
Lens package, you could make another one that includes your common
subset of add-on reader features together.

[Jens Axel Søgaard]

2015-10-16 3:11 GMT+02:00 Neil Van Dyke <ne...@neilvandyke.org>:

Regarding Fortran, about 3 weeks ago, I looked into implementing a `#lang fortran77` or `#lang fortran90`.

... 

  It would be a substantial project, for either a good practical reason or a hobby.)

If you need a practical reason: Having a #lang fortran would make it easy to import

matrix algorithms into Racket.

/Jens Axel

[Hendrik Boom]

On Fri, Oct 16, 2015 at 08:21:09AM -0600, William G Hatch wrote:
>
> FYI, I'm a grad student at Utah with Matthew, and my current project
> is a #lang pre-racket that compiles to C. It hasn't really gotten off
> the ground yet because I've been busy with classes and fellowship
> applications, but in the relatively near future we should have this.

You should look at Gambit. It is a Scheme that compiles to C. It's
probably different from what you're doing, but almost ccertainly
related.

-- hendrik

[Gustavo Massaccesi]

I agree. I think that :xyz doesn't look special enough, and with #:xyz
is clear that the reader is doing something special.

Gustavo

[Sean Kanaley]

While were at it, can we make :long-keyword [3] => :long-keyword [long-keyword 3] ?

And can we make define => =, and = => == ?

In general, can we "Huffman encode" forms by average form usage frequency?

(But seriously, the first one would be nice....)

[Jay McCarthy]

It has been a little more than a week and we've stopped getting results.

The full results should be publicly available. Here is a summary:

https://docs.google.com/forms/d/1HSwtxLhz5HWGMJjMXaO8LQyHJsdMkGbBlRa4fU7Sa34/viewanalytics

and here is the raw data:

https://docs.google.com/spreadsheets/d/1rZNNGwupMZTybxKRhukLdgA8VIA8oPlQ7nPk8Gv52Es/edit#gid=348615477

My interpretation of the data is as follows:

- The #:keyword syntax is liked fine with a rating of 5.67

- The :keyword syntax is more loved with a rating of 6.9

- But change is not popular, average of 5.1 with high standard deviation

- People that really like #:keyword do not want a change and do not like :keyword

- People that really like :keyword want a change

I am genuinely surprised :keyword saw so much support and that change was so attractive to people.

Naturally whenever you do stuff like this, you want to ask more questions, like what about keyword:, what about supporting both, etc.

Jay

On Wed, Oct 14, 2015 at 11:50 AM, Neil Van Dyke <ne...@neilvandyke.org> 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.

That is, when this glorious colon-keywords support is added, instead of having to type and look at:

    (foo #:abc 1 #:xyx 42)

you can choose to bask in the beauty of:

    (foo :abc 1 :xyx 42)

Then you would be free to use the gorgeous colon-keywords everywhere in Racket, including in quick one-line examples in email list posts.

All people of great aesthetic sense, intellect, and good moral fiber, who would naturally like everyone to have the right to use either colon-keywords or (eww) pound-colon keywords (in unity, and without unnecessary `#lang` schisms!), should answer the quick poll:

    http://goo.gl/forms/Kwl3uZVMsb

(When the poll question asks "Is it worth changing?", read it is as "You are a good person, and you naturally think Racket should support both colon-keywords and pound-colon keywords, right?")

I call upon all freedom-loving Racketeers to stand up and fight for the righteous cause of colon-keywords.  The moment to answer this highly scientific poll is now.

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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

           "Wherefore, be not weary in well-doing,
      for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
                          - D&C 64:33

[Leif Andersen]

> I am genuinely surprised :keyword saw so much support and that change was so attractive to people.

That's because of the questions you asked. I saw those questions and said to myself: "Self, I don't care enough about this debate enough to even really fill out these questions." (Although if you had a spot on the pull for the question: "I don't care about this at all, just don't break my code", I would have filled that out.)

~Leif Andersen

[Jay McCarthy]

On Thu, Oct 22, 2015 at 1:49 PM, Leif Andersen <le...@leifandersen.net> wrote:

> I am genuinely surprised :keyword saw so much support and that change was so attractive to people.

That's because of the questions you asked. I saw those questions and said to myself: "Self, I don't care enough about this debate enough to even really fill out these questions." (Although if you had a spot on the pull for the question: "I don't care about this at all, just don't break my code", I would have filled that out.)

I'm interested in your elaboration. I expected someone with your opinion to vote something like 5/5/0 because you don't care between the two, but don't want a change.

Jay

[Leif Andersen]

So, I thought about doing that. Except that I ended up not, because voting 5/5/0 doesn't properly capture my feelings.

5/5/0 seems more like a, I see pros and cons with both sides, but I fundamentally care some way or the other which way this goes.

My opinion really is that this is a silly issue, and doesn't really matter that much to me at all. And thus I don't really care either way. I would vote on the 0 for the last question, (just because meh, I don't care one way or the other), but I really didn't fit anywhere on the spectrum for the first two boxes.

Does that clarify my opinion a bit?

~Leif Andersen

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

[Andrew Gwozdziewycz]

On Thu, Oct 22, 2015 at 10:53 AM, Jay McCarthy <jay.mc...@gmail.com> wrote:

On Thu, Oct 22, 2015 at 1:49 PM, Leif Andersen <le...@leifandersen.net> wrote:

> I am genuinely surprised :keyword saw so much support and that change was so attractive to people.

That's because of the questions you asked. I saw those questions and said to myself: "Self, I don't care enough about this debate enough to even really fill out these questions." (Although if you had a spot on the pull for the question: "I don't care about this at all, just don't break my code", I would have filled that out.)

I'm interested in your elaboration. I expected someone with your opinion to vote something like 5/5/0 because you don't care between the two, but don't want a change.

Interestingly, a 5 is slightly more negative of 'neutral' in your model of 1-10, than 6, which would be slightly more positive than 'neutral'. I wonder how many people picked 5 to be completely neutral, not realizing this subtlety. I guess, the question for me comes down to, "is the volume in question 1 more towards hate?" Or, assuming that some portion of '5's recognized the subtlety and were slightly negative of 'neutral', and the others truly meant 'neutral', it's a dead heat.

(shrug)

[Andrew Gwozdziewycz]

On Thu, Oct 22, 2015 at 11:01 AM, Jack Firth <jackh...@gmail.com> 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...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

http://www.apgwoz.com

[Pierpaolo Bernardi]

On Thu, Oct 22, 2015 at 8:09 PM, Andrew Gwozdziewycz <apg...@gmail.com> 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.

[Neil Van Dyke]

I appreciate people taking the time to vote, and thanks to Jay for doing
this poll.

> I am genuinely surprised :keyword saw so much support and that change
> was so attractive to people.

And I'm surprised how many people claim to love #:keyword. (The
engineering opposition to any non-backward-compatible change was
entirely predictable, but I assumed only a small percentage would
actually prefer #:keyword, due to familiarity or different aesthetic
wiring, and that around half the people would be indifferent to the change.)

This was also a fun exercise for me, because, when I'm consulting on a
large existing system, I'm often the big-bad-meanie who discourages
people adding all the nonstandard general-purpose syntactic tweaks that
they want to. For an especially good general-purpose tweak, my response
is often something like "We should wait and talk with Racket people
about getting that change into the standard". (Though :keyword is my
own baby, not a client's.)

Neil V.

[Alexis King]

> And I'm surprised how many people claim to love #:keyword. (The engineering opposition to any non-backward-compatible change was entirely predictable, but I assumed only a small percentage would actually prefer #:keyword, due to familiarity or different aesthetic wiring, and that around half the people would be indifferent to the change.)

I was going to refrain from saying anything more on this subject (I didn’t respond to the survey at all), but this point interested me. I realized that I’ve grown fond of #:keyword, and I didn’t have any idea why. There have been many times that I’ve found it clunky, or that I’ve missed Clojure or Ruby’s :keywords.

That’s when I realized: Racket doesn’t use its keywords like those languages do. Clojure uses them constantly—it uses them wherever Racket would usually use symbols—and Rails has elevated Ruby’s symbols above literal strings in pure frequency (for better or for worse).

In Ruby, I can do `x = :kw`. In Clojure, I can do (def x :kw). In Racket, I have to do (define x '#:kw), and that is really awful. I need not one but three(!) symbols in front of my raw identifier, and the level of syntactic noise is pretty atrocious. As a side effect of both this and the traditional use of symbols in scheme for this purpose, Racket pretty much only uses keywords for one thing: keyword arguments.

In Racket, a bare #:keyword used as an expression is not just useless, it is a syntax error. A Racket programmer is trained to see keywords in function application alone, so (foo #:kw bar) looks fine, but (foo #:kw) looks weird. They always need to be paired with a value. With keywords so integrally associated with function application syntax, I’ve grown to think of keywords as syntax, never as runtime values, and the hash prefix reinforces this. Heck, even syntax/parse’s :expr syntax class rules out keywords! They are little syntactic tags, nothing more.

For me, this is actually fine. I don’t really mind the verbosity, though making keyword arguments prettier would be nice to have. However, if you are arguing for using keywords as runtime values, that’s an entirely different story... though it does raise the question of how they should be special-cased in function application for keyword arguments (both Ruby and Clojure effectively transform keyword arguments into a single hash argument, rather than making “keyword procedures” that have some special magic).

Basically: keywords are very different in Racket. I don’t know much CL, so I can’t speak to that, but I think there’s more going on here than syntax. If that’s the case, omitting a hash would only solve a portion of the problem... and Racket programmers might not view their keywords in the same light as those from other languages. I certainly didn’t.

Sorry for the rambling... but maybe some food for thought.

Alexis

[John Berry]

Yes, speaking personally, if I think about what I mean when I think about :keyword over #:keyword, what I really am after is the difference Alexis describes: of keywords as values vs. keywords as syntax.

And looked at that way, it really just seems to be a question of different idioms, that of older Lisp/Scheme style vs. the Clojure style I got accustomed to on my day job.

[Greg Hendershott]

Keyword arguments: Although I'm comfortable in the #: camp, I can
understand people preferring :foo over #:foo for the reason that it is
faster to type. #: requires two shifted chars. If you touch type you
use both left and right shift keys O_o. In that respect #: is even
more awkward a finger dance than #%. :) Although it doesn't bother me
that much, and I don't think it should change, I do understand.
However...

Symbol(ish) values: I don't understand preferring :foo over 'foo.
It's more typing not less. And more basically, just why? I don't
understand having two symbol-ish value flavors. People new to lisp
already have trouble understanding the how and why of symbols.^1
Having two flavors of this seems like a distinction without a
difference; what am I overlooking?

^1: Example: http://stackoverflow.com/questions/8846628/what-exactly-is-a-symbol-in-lisp-scheme

[Anthony Carrico]

On 10/23/2015 11:30 AM, Greg Hendershott wrote:
> If you touch type you
> use both left and right shift keys O_o.

...but only the right shift key in dvorak, but seriously Asumu mentioned
Flatt and Barzilay's "Keyword and optional arguments in PLT Scheme" on
irc last night:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.162.17
The paper illuminates the history and all the issues raised is this thread.

--
Anthony Carrico

[William G Hatch]

On Fri, Oct 23, 2015 at 02:58:30PM -0400, Anthony Carrico wrote:
>On 10/23/2015 11:30 AM, Greg Hendershott wrote:
>> If you touch type you
>> use both left and right shift keys O_o.
>
>...but only the right shift key in dvorak

For greater keyboard layout awareness, here is a more complete
assessment of the situation:

Arensito, Qwertz, Hacker's Dvorak, and Maltron layouts: 3 keys (adding #
is only one extra key because it is unshifted).

Hatchak and Azerty layouts: 3 keys (although it's two for # and one for
:)

Dvorak and Capewell need them both shifted but only one side's shift key.

Neo, Coleman, and Workman all take 4 keys like Qwerty.

#: is onerous for both left and right versions of one-handed Dvorak,
since both require shifting and are on opposite sides of the keyboard.
And I assume you only use these layouts if you have to type one-handed.

On the default AOSP touch keyboard, it take 3 touches to type #:, which
is only 1 more than : alone.

But seriously, I'm totally on the side of #:. In no layout is it such a
burden to occasionally type #:, and if you worry about typing efficiency
or ergonomics a better plan is to switch away from qwerty. Visually I
think #: gives better emphasis to keywords' special purpose.

- William

[Greg Hendershott]

On Fri, Oct 23, 2015 at 2:58 PM, Anthony Carrico <acar...@memebeam.org> wrote:
> but seriously Asumu mentioned
> Flatt and Barzilay's "Keyword and optional arguments in PLT Scheme" on
> irc last night:
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.162.17
> The paper illuminates the history and all the issues raised is this thread.

Thanks! That's helpful. I should have thought to go look for a paper about this.

p.s. If people read that (even just section 7.7), and there's still a
debate? Then probably the only resolution would be a compromise that
leaves everyone equally unhappy. Like say :#:keyword:#: ;)

[Neil Van Dyke]

Greg Hendershott wrote on 10/24/2015 10:43 AM:
> p.s. If people read that (even just section 7.7), and there's still a
> debate? Then probably the only resolution would be a compromise that
> leaves everyone equally unhappy. Like say :#:keyword:#: ;)

I linked the paper on Oct 15, though it got lost in the volume. Quoting
from section 7.7:

> We can offer no rationale that will resolve the debate. We chose #:
> because it broke no existing code and because at least one author
> likes how it stands out. An informal poll among PLT Scheme users
> suggested roughly equal support for all three choices (prefix #:,
> prefix :, and suffix :) with a slightly higher preference for
> #:—possibly reflecting the syntax that is already in place. In any
> case, PLT Scheme’s #lang notation would allow future modules to be
> written using a different syntax without affecting old modules.

The rationale for `#:`, aside from a subjective visual-perceptual call,
was that it "broke no existing code".

As I said on Oct 15, speaking in retrospect:

> The Scheme situation is discouraging, and I'm glad that Racket (PLT
> Scheme) went ahead and did something. However, I wish we all had cared
> slightly less about R5RS compatibility and such back then (especially
> since R5RS compatibility has been abandoned in much larger ways in
> Racket today, such as in pair mutability). Perhaps I could've been
> using colon-prefix happily the last several years. And also, no one
> would have introduced the few problematic colon-symbols that now have
> to be considered before adding colon-prefix keywords today.

I don't like the `#lang` option, mostly because of the effective
fragmentation of the language that the community uses informally
*outside of* modules.

Though Matthias points out that fragmentation happens, and he
distinguishes linguistic fragmentation from social fragmentation, with
the latter sounding worse.

I suppose that `#lang paddle` could correct Racket's linguistic
naughtiness, while somehow retaining a cohesive social unit, but you
know that's eventually going to come up in therapy.

Neil V.

[Jordan Johnson]

On Oct 23, 2015, at 8:30 AM, Greg Hendershott <greghen...@gmail.com> wrote:

Keyword arguments:  Although I'm comfortable in the #: camp, I can

understand people preferring :foo over #:foo for the reason that it is
faster to type. #: requires two shifted chars. If you touch type you
use both left and right shift keys O_o. 

Catching up late on this discussion, I found only the above surprising; I touch-type, but always use left-shift for both hash and colon.

Maybe it's a lefty thing.

FWIW, I'm in the "please don't break existing code for this reason" camp, though I also appreciate the extra visual distinction of an octothorp'd keyword.

Best,

Jordan

[Hendrik Boom]

On Mon, Oct 26, 2015 at 09:35:22PM -0700, Jordan Johnson wrote:
> On Oct 23, 2015, at 8:30 AM, Greg Hendershott <greghen...@gmail.com> wrote:
> > Keyword arguments: Although I'm comfortable in the #: camp, I can
> > understand people preferring :foo over #:foo for the reason that it is
> > faster to type. #: requires two shifted chars. If you touch type you
> > use both left and right shift keys O_o.
>
> Catching up late on this discussion, I found only the above surprising; I touch-type, but always use left-shift for both hash and colon.
>
> Maybe it's a lefty thing.

For me, using left-shiftt is a leftover fro the old days of keypunches,
where you used the left shift to put it in numeric mode. All the digitw
were on the right. Once the knowledge is in the fingers it lasts a long
time.

-- hendrik

[Nota Poin]

On Wednesday, October 14, 2015 at 3:50:44 PM UTC, Neil Van Dyke wrote:
> (foo :abc 1 :xyx 42)

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

and (foo #:bar? #t)

we would have:

(define (foo (bar? #f) (foo 42) (some-variable-name 3))

It's the keyworded define and lambda syntax that I find sloppy and ugly.

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

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

[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

[George Neuner]

Coming late to this.

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

<ne...@neilvandyke.org> 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

[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

[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

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

[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