Re: [racket-users] Re: FFI Library Naming Conventions

[Hendrik Boom]

On Mon, Jan 09, 2017 at 06:56:06AM -0500, Neil Van Dyke wrote:

> * (One argument *against* using Racket idiomatic names for a big API, such
> as OpenGL, is that sometimes you might really want to make the names look
> like the C ones, such as for people copying large masses of example code.
> I'm not going to try to tackle that discussion at this time, but will just
> note that transliterating some small OpenGL code samples a long time ago was
> not a big deal "http://www.neilvandyke.org/opengl-plt/;.)

One issue here is documentation.  The Racket names in a library should 
be systematically related to the C ones unless we want to rewrite all 
the documentation.

-- hendrik

-- 
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: FFI Library Naming Conventions

[Neil Van Dyke]

* Remember that, although Racket is rich with various kinds of 
namespaces, documentation lookup for the core Racket and add-on packages 
really prefer that names are mostly unique globally.  (I won't get into 
readability tradeoffs, for various use cases that come up.)  See thread 
"http://lists.racket-lang.org/dev/archive/2014-July/014456.html;.


* For one of numerous examples of what I currently think is 
usually-good-enough naming practice in reusable Racket packages, see 
"http://www.neilvandyke.org/racket/roomba/;, which works the package 
name into every public identifier, while remaining fairly 
English-verbs-and-nouns-readable.  (Even though, in the particular case 
of a package of Roomba commands, we could make a good argument that they 
should be shorter and more generic, since one obvious audience is young 
children doing Logo-ish programming.  I decided that's probably not a 
good enough argument, and if we wanted that, that particular use wants 
to be a "#lang".  Which documentation searches and readability can and 
should really handle differently.)


* Exporting both prefixed and non-prefixed identifiers from a package 
pollutes the global documentation namespace.


* I think the original question might have also been asking about the 
exact character forms of names from FFI, not just whether prefixed.  One 
convenient accident of naming convention differences between C and 
Racket (e.g., underscores), when doing FFI, is that we can usually use 
the C names in Racket, internally, for procedures with the most bare FFI 
wrappers.  That leaves the idiomatic Racket names for the exposed 
interface, which might also layer small safeties and other features. And 
not exporting the non-Racket-idiomatic C names from Racket packages 
avoids messing up the readability of all code that uses the packages.


* (One argument *against* using Racket idiomatic names for a big API, 
such as OpenGL, is that sometimes you might really want to make the 
names look like the C ones, such as for people copying large masses of 
example code.  I'm not going to try to tackle that discussion at this 
time, but will just note that transliterating some small OpenGL code 
samples a long time ago was not a big deal 
"http://www.neilvandyke.org/opengl-plt/;.)


* I can't resist the opportunity to reiterate one naming convention 
plea: Don't use uppercase identifiers for "constants" in Racket.  It was 
that way in K C because people used the really linguistically nasty 
macro preprocessor for constants (among other purposes).  Then someone 
started using the same thing for some better form of constants in ANSI C 
and C++, making the terrible mistake of thinking that names of constants 
should be uppercase in C/C++ code.  (Then Java picked it up, as one of 
its many attempts to appeal to the small pool of technical and embedded 
systems programmers, which was funny, because all those C accidents of 
implementation convenience from the 1970s were then forced on the 
less-technical MIS-type programmers who overwhelmingly took over Java, 
and who never had any need for things to look like cryptic C.)  The 
uppercase is hard to type, visually misleading regarding importance, and 
a very poor use of a visually powerful mechanism.  I think that the best 
use of upper-case names in Racket is for pattern variables in syntax 
transformers, to stand out amongst fragments of code.  Using uppercase 
for constants compromises that.


--
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: FFI Library Naming Conventions

[Jens Axel Søgaard]

Using prefix-out it is easy to provide the end user with both options.
One module exports the bindings without the library name prefix.
The other simply imports and reexports all bindings using prefix-out.

/Jens Axel

2017-01-08 23:18 GMT+01:00 Hendrik Boom :

> On Sun, Jan 08, 2017 at 01:43:09PM -0800, Lehi Toskin wrote:
> > On Sunday, January 8, 2017 at 8:29:49 AM UTC-8, Royall Spence wrote:
> > > I'm making some bindings for a C library. In the original library, the
> functions are named as "LIBNAME_do_stuff". Should I keep those the same in
> the FFI binding or define them as "libname-do-stuff"? Is there a convention
> for these things?
> >
> > What I like to do is libname-do-stuff, but I'm partial to the idea of
> dropping the libname part and instead just having do-stuff. That is, unless
> there's frequent naming conflicts.
>
> As a reader of programs, I find it very helpful when encountering a
> name for it to be easy to find the library that defines it.
>
> -- hendrik
>
> --
> 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.
>



-- 
-- 
Jens Axel Søgaard

-- 
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: FFI Library Naming Conventions

[Hendrik Boom]

On Sun, Jan 08, 2017 at 01:43:09PM -0800, Lehi Toskin wrote:
> On Sunday, January 8, 2017 at 8:29:49 AM UTC-8, Royall Spence wrote:
> > I'm making some bindings for a C library. In the original library, the 
> > functions are named as "LIBNAME_do_stuff". Should I keep those the same in 
> > the FFI binding or define them as "libname-do-stuff"? Is there a convention 
> > for these things?
> 
> What I like to do is libname-do-stuff, but I'm partial to the idea of 
> dropping the libname part and instead just having do-stuff. That is, unless 
> there's frequent naming conflicts.

As a reader of programs, I find it very helpful when encountering a 
name for it to be easy to find the library that defines it.

-- hendrik

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