Re: [racket-users] Re: Library function naming

[Jeremiah Peschka]

I believe OP is referring to the paragraph about
play-with-frisky-with-laser being their default style and their sincere
recommendation for Racket code style.

It also seems to be the style that most closely matches core APIs.


On August 29, 2017 at 11:23:51, David Storrs (david.sto...@gmail.com) wrote:



On Tue, Aug 29, 2017 at 6:12 AM, Neil Van Dyke  wrote:

>
>
> (Of course, other general conventions also have their merits, in various
> languages and environments.  For example `FrskyLsr_szGetColor()`.  And
> `com.example.FriskyLaser.FriskyLaserPlayBehavior.play` and unqualified
> form `play`.  What I mentioned above is my current default convention for
> Racket when I don't think of good reason to do it differently, and am not
> experimenting/playing with doing it differently as an exercise.)
>

Is this actually a sincere recommendation for Racket code?  Because,
personally, I think Java-style naming is an abomination before the Turing
and should be avoided at all costs.  Maybe that's just me, though.
--
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.

-- 
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: Library function naming

[David Storrs]

On Tue, Aug 29, 2017 at 6:12 AM, Neil Van Dyke  wrote:

>
>
> (Of course, other general conventions also have their merits, in various
> languages and environments.  For example `FrskyLsr_szGetColor()`.  And
> `com.example.FriskyLaser.FriskyLaserPlayBehavior.play` and unqualified
> form `play`.  What I mentioned above is my current default convention for
> Racket when I don't think of good reason to do it differently, and am not
> experimenting/playing with doing it differently as an exercise.)
>

Is this actually a sincere recommendation for Racket code?  Because,
personally, I think Java-style naming is an abomination before the Turing
and should be avoided at all costs.  Maybe that's just me, though.

-- 
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: Library function naming

[Greg Hendershott]

It's also worth considering that you can munge the names when you
provide -- and your users can munge them on require.

See filtered-out and filtered-in -- as well as the more commonly used
conveniences built on them, like prefix-{in out}, rename-{in out}, and
so on.


I think sometimes the goodness of a name can depend on the context
where it's being used.

If I'm implementing functions in money.rkt, it might be tedious to
have "money- money- money- money-" everywhere. The low signal:noise
ratio might detract from readability. Might cause expressions not to
fit on one line. And so on. If that bothers me, I can name functions
deposit and convert, and (provide (prefix-out money- deposit convert)
so users see money-deposit, money-convert.

It's also an interesting option to provide just the short names
deposit and convert, and assume that users will (require (prefix-in
money- "money.rkt")) -- or whatever prefix they want. Although this is
idiomatic in some langs/communities, it's not AFAICT in Racket.

Fortunately Racket makes it easy to adapt provided and required names.

-- 
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: Library function naming

[Laurent]

On Tue, Aug 29, 2017 at 11:12 AM, Neil Van Dyke 
wrote:

>
> (Someday, I will have time to release a package that changes how
> `define-struct`/`struct` identifiers are generated, to use `.` or `:`.  To
> at least have the appearance of being more idiomatic, to hint at the
> various other specialness, and to avoid the frequent naming collisions when
> you want to provide encapsulating behavior around struct field accessors.)
>
>
+1!

-- 
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: Library function naming

[Neil Van Dyke]

I recommend trying to develop most non-core Racket modules as if you 
might want to share them as small reusable third-party open source 
packages in the near future.  Which has implications for naming.


For reusable third-party Racket packages, right now, I recommend usually 
trying to include the package name (or at least a noun or verb part of a 
package name) in each identifier provided by the package.  (This isn't a 
perfect approach considering of a large distributed flat namespace of 
provides of all the third-party packages, and you don't have to do it 
every time, but I think it's usually pretty good balance of a number of 
goals.)


Also, for other reasons, consider making provided procedures named as 
English sentences.  (Remember that Racket procedures are evaluated 
imperatively.)


For example, If your package is named `frisky` (a cat), you might 
provide procedures such as `feed-frisky`, `display-frisky`, and 
`animate-frisky`.


For another example, let's say someone else makes a package that 
augments package `frisky`, and calls their package `frisky-laser`, and 
might provide procedures like `play-with-frisky-with-laser`.


This reduces name collisions, often reads pretty easily, is a good 
convention to pick for naming consistency, and gives some imperfect 
sense of various identifiers' packages when glancing at a block of 
reusing code.


(Of course, other general conventions also have their merits, in various 
languages and environments.  For example `FrskyLsr_szGetColor()`.  And 
`com.example.FriskyLaser.FriskyLaserPlayBehavior.play` and unqualified 
form `play`.  What I mentioned above is my current default convention 
for Racket when I don't think of good reason to do it differently, and 
am not experimenting/playing with doing it differently as an exercise.)


(Someday, I will have time to release a package that changes how 
`define-struct`/`struct` identifiers are generated, to use `.` or `:`.  
To at least have the appearance of being more idiomatic, to hint at the 
various other specialness, and to avoid the frequent naming collisions 
when you want to provide encapsulating behavior around struct field 
accessors.)


--
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: Library function naming

[Laurent]

The style guide Jack mentions is not really about the /library's/ name, but
rather about the data type of the main (usually the first) argument, as
saide. For example you could have a library called `my-wonderful-lib' that
experts `vector-splendify', which takes a vector as its first argument.

On Mon, Aug 28, 2017 at 10:26 PM, Jack Firth  wrote:

> The Racket Style Guide[1] has some notes about this in the Textual
> Matters: Names[2] section:
>
> > Use meaningful names. The Lisp convention is to use full English words
> separated by dashes. Racket code benefits from the same convention.
> > Note that _ (the underline character) is also classified as bad
> Racketeering within names. It is an acceptable placeholder in syntax
> patterns, match patterns, and parameters that don’t matter.
> > Another widely used convention is to prefix a function name with the
> data type of the main argument. This convention generalizes the
> selector-style naming scheme of struct.
>
> So yes, if you were to write a `money` library many Racketeers would
> expect it to export functions like `money-deposit` and `money-convert`.
> This has the advantage that searching "money" in Scribble will give a quick
> list of the exports of "money", since they'll all have the prefix. This
> isn't a hard and fast rule, merely a guideline.
>
> [1] http://docs.racket-lang.org/style/index.html
> [2] http://docs.racket-lang.org/style/Textual_Matters.html#%
> 28part._names%29
>
> --
> 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.
>

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