Allow specifying services as symbols?

Allow specifying services as symbols?

[Lars Magne Ingebrigtsen]

It was suggested that we should allow specifying port names (e.g.,
"imap") as symbols, too, in addition to strings and numbers.  Any
objections to something like the following?

=== modified file 'src/process.c'
*** src/process.c	2010-10-08 10:14:47 +0000
--- src/process.c	2010-10-19 18:06:05 +0000
***************
*** 2977,2987 ****
  for a server process, it must be a valid name or address for the local
  host, and only clients connecting to that address will be accepted.
  
! :service SERVICE -- SERVICE is name of the service desired, or an
! integer specifying a port number to connect to.  If SERVICE is t,
! a random port number is selected for the server.  (If Emacs was
! compiled with getaddrinfo, a port number can also be specified as a
! string, e.g. "80", as well as an integer.  This is not portable.)
  
  :type TYPE -- TYPE is the type of connection.  The default (nil) is a
  stream type connection, `datagram' creates a datagram type connection,
--- 2977,2988 ----
  for a server process, it must be a valid name or address for the local
  host, and only clients connecting to that address will be accepted.
  
! :service SERVICE -- SERVICE is name of the service desired (a string
! or a symbol) or an integer specifying a port number to connect to.  If
! SERVICE is t, a random port number is selected for the server.  (If
! Emacs was compiled with getaddrinfo, a port number can also be
! specified as a string, e.g. "http", as well as an integer.  This is
! not portable.)
  
  :type TYPE -- TYPE is the type of connection.  The default (nil) is a
  stream type connection, `datagram' creates a datagram type connection,
***************
*** 3313,3318 ****
--- 3314,3323 ----
  	  sprintf (portbuf, "%ld", (long) XINT (service));
  	  portstring = portbuf;
  	}
+       else if (SYMBOLP (service))
+ 	{
+ 	  portstring = SDATA (SYMBOL_NAME (service));
+ 	}
        else
  	{
  	  CHECK_STRING (service);



-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Allow specifying services as symbols?

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 19 Oct 2010 20:07:46 +0200
> 
> It was suggested that we should allow specifying port names (e.g.,
> "imap") as symbols, too, in addition to strings and numbers.  Any
> objections to something like the following?

If this is accepted, please also update the ELisp manual.

Thanks.

Re: Allow specifying services as symbols?

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Tue, 19 Oct 2010 20:07:46 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> It was suggested that we should allow specifying port names (e.g.,
LMI> "imap") as symbols, too, in addition to strings and numbers.  Any
LMI> objections to something like the following?

My patch, attached here, corrects the docstring and fixes the two places
where the port should be a symbol (you only got one, I think, because of
the "goto open_socket" right before "#endif /* HAVE_GETADDRINFO */").

I'll write a manual patch as well if this is acceptable.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-network-connection-with-symbol-service.patch --]
[-- Type: text/x-diff, Size: 1807 bytes --]

=== modified file 'src/process.c'
--- src/process.c	2010-10-08 10:14:47 +0000
+++ src/process.c	2010-10-19 18:26:51 +0000
@@ -2978,10 +2978,11 @@
 host, and only clients connecting to that address will be accepted.
 
 :service SERVICE -- SERVICE is name of the service desired, or an
-integer specifying a port number to connect to.  If SERVICE is t,
-a random port number is selected for the server.  (If Emacs was
-compiled with getaddrinfo, a port number can also be specified as a
-string, e.g. "80", as well as an integer.  This is not portable.)
+integer specifying a port number to connect to.  If SERVICE is t, a
+random port number is selected for the server.  A port number can also
+be specified as a string, e.g. "80", or a symbol whose name will be
+used, as well as an integer.  This is not necessarily portable; either
+getaddrinfo or getservbyname will be used to look up the port number.
 
 :type TYPE -- TYPE is the type of connection.  The default (nil) is a
 stream type connection, `datagram' creates a datagram type connection,
@@ -3303,6 +3304,11 @@
      Otherwise, use getservbyname to lookup the service.  */
   if (!NILP (host))
     {
+      /* Take a symbol as the service and convert it to a string.  */
+      if (SYMBOLP (service))
+	{
+	  service = Fsymbol_name (service);
+	}
 
       /* SERVICE can either be a string or int.
 	 Convert to a C string for later use by getaddrinfo.  */
@@ -3347,6 +3353,12 @@
   /* We end up here if getaddrinfo is not defined, or in case no hostname
      has been specified (e.g. for a local server process).  */
 
+  /* Take a symbol as the service and convert it to a string.  */
+  if (SYMBOLP (service))
+    {
+      service = Fsymbol_name (service);
+    }
+
   if (EQ (service, Qt))
     port = 0;
   else if (INTEGERP (service))

Re: Allow specifying services as symbols?

[Chong Yidong]

Ted Zlatanov <tzz@lifelogs.com> writes:

> My patch, attached here, corrects the docstring and fixes the two places
> where the port should be a symbol (you only got one, I think, because of
> the "goto open_socket" right before "#endif /* HAVE_GETADDRINFO */").
>
> I'll write a manual patch as well if this is acceptable.

Seems OK to me.

Re: Allow specifying services as symbols?

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

On Tue, 19 Oct 2010 16:17:08 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> Ted Zlatanov <tzz@lifelogs.com> writes:
>> My patch, attached here, corrects the docstring and fixes the two places
>> where the port should be a symbol (you only got one, I think, because of
>> the "goto open_socket" right before "#endif /* HAVE_GETADDRINFO */").
>> 
>> I'll write a manual patch as well if this is acceptable.

CY> Seems OK to me.

The patch to the manual and the code is below.  I can't commit it until
much later, so if anyone wants to do it sooner, feel free.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-network-connection-with-symbol-service.patch --]
[-- Type: text/x-diff, Size: 3317 bytes --]

=== modified file 'doc/lispref/processes.texi'
--- doc/lispref/processes.texi	2010-08-25 05:23:47 +0000
+++ doc/lispref/processes.texi	2010-10-19 21:22:42 +0000
@@ -1937,9 +1937,10 @@
 @var{buffer-or-name} is @code{nil}, it means that the connection is not
 associated with any buffer.
 
-The arguments @var{host} and @var{service} specify where to connect to;
-@var{host} is the host name (a string), and @var{service} is the name of
-a defined network service (a string) or a port number (an integer).
+The arguments @var{host} and @var{service} specify where to connect
+to; @var{host} is the host name (a string), and @var{service} is the
+name of a defined network service (a string or a symbol) or a port
+number (an integer).
 @end defun
 
 @node Network Servers
@@ -2076,10 +2077,10 @@
 
 @item :service @var{service}
 @var{service} specifies a port number to connect to, or, for a server,
-the port number to listen on.  It should be a service name that
-translates to a port number, or an integer specifying the port number
-directly.  For a server, it can also be @code{t}, which means to let
-the system select an unused port number.
+the port number to listen on.  It should be a service name (a string
+or a symbol) that translates to a port number, or an integer
+specifying the port number directly.  For a server, it can also be
+@code{t}, which means to let the system select an unused port number.
 
 @item :family @var{family}
 @var{family} specifies the address (and protocol) family for

=== modified file 'src/process.c'
--- src/process.c	2010-10-08 10:14:47 +0000
+++ src/process.c	2010-10-19 18:26:51 +0000
@@ -2978,10 +2978,11 @@
 host, and only clients connecting to that address will be accepted.
 
 :service SERVICE -- SERVICE is name of the service desired, or an
-integer specifying a port number to connect to.  If SERVICE is t,
-a random port number is selected for the server.  (If Emacs was
-compiled with getaddrinfo, a port number can also be specified as a
-string, e.g. "80", as well as an integer.  This is not portable.)
+integer specifying a port number to connect to.  If SERVICE is t, a
+random port number is selected for the server.  A port number can also
+be specified as a string, e.g. "80", or a symbol whose name will be
+used, as well as an integer.  This is not necessarily portable; either
+getaddrinfo or getservbyname will be used to look up the port number.
 
 :type TYPE -- TYPE is the type of connection.  The default (nil) is a
 stream type connection, `datagram' creates a datagram type connection,
@@ -3303,6 +3304,11 @@
      Otherwise, use getservbyname to lookup the service.  */
   if (!NILP (host))
     {
+      /* Take a symbol as the service and convert it to a string.  */
+      if (SYMBOLP (service))
+	{
+	  service = Fsymbol_name (service);
+	}
 
       /* SERVICE can either be a string or int.
 	 Convert to a C string for later use by getaddrinfo.  */
@@ -3347,6 +3353,12 @@
   /* We end up here if getaddrinfo is not defined, or in case no hostname
      has been specified (e.g. for a local server process).  */
 
+  /* Take a symbol as the service and convert it to a string.  */
+  if (SYMBOLP (service))
+    {
+      service = Fsymbol_name (service);
+    }
+
   if (EQ (service, Qt))
     port = 0;
   else if (INTEGERP (service))

Re: Allow specifying services as symbols?

[Davis Herring]

> ! :service SERVICE -- SERVICE is name of the service desired (a string
> ! or a symbol) or an integer specifying a port number to connect to.  If
> ! SERVICE is t, a random port number is selected for the server.  (If
> ! Emacs was compiled with getaddrinfo, a port number can also be
> ! specified as a string, e.g. "http", as well as an integer.  This is
> ! not portable.)

As more of a philosophical objection than anything, t is a symbol.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Allow specifying services as symbols?

[Chong Yidong]

"Davis Herring" <herring@lanl.gov> writes:

>> ! :service SERVICE -- SERVICE is name of the service desired (a string
>> ! or a symbol) or an integer specifying a port number to connect to.  If
>> ! SERVICE is t, a random port number is selected for the server.  (If
>> ! Emacs was compiled with getaddrinfo, a port number can also be
>> ! specified as a string, e.g. "http", as well as an integer.  This is
>> ! not portable.)
>
> As more of a philosophical objection than anything, t is a symbol.

Hmm, good catch.  So's nil.

So let's back up for a moment, here.  Lars, could you provide an example
that shows why it's convenient to allow symbols to name services?

Re: Allow specifying services as symbols?

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

>> As more of a philosophical objection than anything, t is a symbol.
>
> Hmm, good catch.  So's nil.

True.  Perhaps this isn't a good idea after all.  It's just come more
than a few times over the years that people are using 'nntp instead of
"nntp" and 'imap instead of "imap" and not understanding why they're
getting errors.

Since these are things that users mess around with, I thought it might
be user-friendly to allow these forms, but I don't really care.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Allow specifying services as symbols?

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Tue, 19 Oct 2010 18:20:55 -0400 Chong Yidong <cyd@stupidchicken.com> wrote: 

CY> "Davis Herring" <herring@lanl.gov> writes:
>>> ! :service SERVICE -- SERVICE is name of the service desired (a string
>>> ! or a symbol) or an integer specifying a port number to connect to.  If
>>> ! SERVICE is t, a random port number is selected for the server.  (If
>>> ! Emacs was compiled with getaddrinfo, a port number can also be
>>> ! specified as a string, e.g. "http", as well as an integer.  This is
>>> ! not portable.)
>> 
>> As more of a philosophical objection than anything, t is a symbol.

CY> Hmm, good catch.  So's nil.

OK, I will exclude t and nil.  That was a problem with the patch (t was
converted to "t" and nil to "nil").  Thanks for catching that!  Revised
version attached.

CY> So let's back up for a moment, here.  Lars, could you provide an example
CY> that shows why it's convenient to allow symbols to name services?

The issue came up as a customization user-side problem and I suggested
allowing symbols.  Using symbols is consistent with many other Emacs
facilities (too many to list) that use symbols to enumerate a small set
of choices.  It makes customization simpler and less error-prone for
software that uses `make-network-process'.  It doesn't really cost
anything.  The only downside is that if in the future we decide to add
options to the :service parameter besides t and nil, they won't be easy
to retrofit.

It's really not a big deal though, so if you're concerned about the
downside I listed or any others, let's kill the idea.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-network-connection-with-symbol-service.patch --]
[-- Type: text/x-diff, Size: 3397 bytes --]

=== modified file 'doc/lispref/processes.texi'
--- doc/lispref/processes.texi	2010-08-25 05:23:47 +0000
+++ doc/lispref/processes.texi	2010-10-20 11:18:48 +0000
@@ -1937,9 +1937,10 @@
 @var{buffer-or-name} is @code{nil}, it means that the connection is not
 associated with any buffer.
 
-The arguments @var{host} and @var{service} specify where to connect to;
-@var{host} is the host name (a string), and @var{service} is the name of
-a defined network service (a string) or a port number (an integer).
+The arguments @var{host} and @var{service} specify where to connect
+to; @var{host} is the host name (a string), and @var{service} is the
+name of a defined network service (a string or a symbol) or a port
+number (an integer).
 @end defun
 
 @node Network Servers
@@ -2076,10 +2077,10 @@
 
 @item :service @var{service}
 @var{service} specifies a port number to connect to, or, for a server,
-the port number to listen on.  It should be a service name that
-translates to a port number, or an integer specifying the port number
-directly.  For a server, it can also be @code{t}, which means to let
-the system select an unused port number.
+the port number to listen on.  It should be a service name (a string
+or a symbol) that translates to a port number, or an integer
+specifying the port number directly.  For a server, it can also be
+@code{t}, which means to let the system select an unused port number.
 
 @item :family @var{family}
 @var{family} specifies the address (and protocol) family for

=== modified file 'src/process.c'
--- src/process.c	2010-10-08 10:14:47 +0000
+++ src/process.c	2010-10-20 11:20:53 +0000
@@ -2978,10 +2978,11 @@
 host, and only clients connecting to that address will be accepted.
 
 :service SERVICE -- SERVICE is name of the service desired, or an
-integer specifying a port number to connect to.  If SERVICE is t,
-a random port number is selected for the server.  (If Emacs was
-compiled with getaddrinfo, a port number can also be specified as a
-string, e.g. "80", as well as an integer.  This is not portable.)
+integer specifying a port number to connect to.  If SERVICE is t, a
+random port number is selected for the server.  A port number can also
+be specified as a string, e.g. "80", or a symbol whose name will be
+used, as well as an integer.  This is not necessarily portable; either
+getaddrinfo or getservbyname will be used to look up the port number.
 
 :type TYPE -- TYPE is the type of connection.  The default (nil) is a
 stream type connection, `datagram' creates a datagram type connection,
@@ -3303,6 +3304,11 @@
      Otherwise, use getservbyname to lookup the service.  */
   if (!NILP (host))
     {
+      /* Take a symbol as the service and convert it to a string.  */
+      if (!NILP (service) && !EQ (service, Qt) && SYMBOLP (service))
+	{
+	  service = Fsymbol_name (service);
+	}
 
       /* SERVICE can either be a string or int.
 	 Convert to a C string for later use by getaddrinfo.  */
@@ -3347,6 +3353,12 @@
   /* We end up here if getaddrinfo is not defined, or in case no hostname
      has been specified (e.g. for a local server process).  */
 
+  /* Take a symbol as the service and convert it to a string.  */
+  if (!NILP (service) && !EQ (service, Qt) && SYMBOLP (service))
+    {
+      service = Fsymbol_name (service);
+    }
+
   if (EQ (service, Qt))
     port = 0;
   else if (INTEGERP (service))

Re: Allow specifying services as symbols?

[Andreas Schwab]

Ted Zlatanov <tzz@lifelogs.com> writes:

> @@ -3303,6 +3304,11 @@
>       Otherwise, use getservbyname to lookup the service.  */
>    if (!NILP (host))
>      {
> +      /* Take a symbol as the service and convert it to a string.  */
> +      if (!NILP (service) && !EQ (service, Qt) && SYMBOLP (service))
> +	{
> +	  service = Fsymbol_name (service);
> +	}
>  
>        /* SERVICE can either be a string or int.
>  	 Convert to a C string for later use by getaddrinfo.  */

Why not just move the hunk down to where service is checked for being a
string?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Allow specifying services as symbols?

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

On Wed, 20 Oct 2010 13:52:11 +0200 Andreas Schwab <schwab@linux-m68k.org> wrote: 

AS> Why not just move the hunk down to where service is checked for being a
AS> string?

That would be smarter, yes.  In the second place it was not a simple "if
else" so I somehow didn't think to do it correctly.  See the attached
third patch.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make-network-connection-with-symbol-service.patch --]
[-- Type: text/x-diff, Size: 3468 bytes --]

=== modified file 'doc/lispref/processes.texi'
--- doc/lispref/processes.texi	2010-08-25 05:23:47 +0000
+++ doc/lispref/processes.texi	2010-10-20 11:18:48 +0000
@@ -1937,9 +1937,10 @@
 @var{buffer-or-name} is @code{nil}, it means that the connection is not
 associated with any buffer.
 
-The arguments @var{host} and @var{service} specify where to connect to;
-@var{host} is the host name (a string), and @var{service} is the name of
-a defined network service (a string) or a port number (an integer).
+The arguments @var{host} and @var{service} specify where to connect
+to; @var{host} is the host name (a string), and @var{service} is the
+name of a defined network service (a string or a symbol) or a port
+number (an integer).
 @end defun
 
 @node Network Servers
@@ -2076,10 +2077,10 @@
 
 @item :service @var{service}
 @var{service} specifies a port number to connect to, or, for a server,
-the port number to listen on.  It should be a service name that
-translates to a port number, or an integer specifying the port number
-directly.  For a server, it can also be @code{t}, which means to let
-the system select an unused port number.
+the port number to listen on.  It should be a service name (a string
+or a symbol) that translates to a port number, or an integer
+specifying the port number directly.  For a server, it can also be
+@code{t}, which means to let the system select an unused port number.
 
 @item :family @var{family}
 @var{family} specifies the address (and protocol) family for

=== modified file 'src/process.c'
--- src/process.c	2010-10-08 10:14:47 +0000
+++ src/process.c	2010-10-20 12:26:46 +0000
@@ -2978,10 +2978,11 @@
 host, and only clients connecting to that address will be accepted.
 
 :service SERVICE -- SERVICE is name of the service desired, or an
-integer specifying a port number to connect to.  If SERVICE is t,
-a random port number is selected for the server.  (If Emacs was
-compiled with getaddrinfo, a port number can also be specified as a
-string, e.g. "80", as well as an integer.  This is not portable.)
+integer specifying a port number to connect to.  If SERVICE is t, a
+random port number is selected for the server.  A port number can also
+be specified as a string, e.g. "80", or a symbol whose name will be
+used, as well as an integer.  This is not necessarily portable; either
+getaddrinfo or getservbyname will be used to look up the port number.
 
 :type TYPE -- TYPE is the type of connection.  The default (nil) is a
 stream type connection, `datagram' creates a datagram type connection,
@@ -3303,7 +3304,6 @@
      Otherwise, use getservbyname to lookup the service.  */
   if (!NILP (host))
     {
-
       /* SERVICE can either be a string or int.
 	 Convert to a C string for later use by getaddrinfo.  */
       if (EQ (service, Qt))
@@ -3313,6 +3313,11 @@
 	  sprintf (portbuf, "%ld", (long) XINT (service));
 	  portstring = portbuf;
 	}
+      /* Take a symbol as the service and convert it to a string.  */
+      else if (SYMBOLP (service))
+	{
+	  service = Fsymbol_name (service);
+	}
       else
 	{
 	  CHECK_STRING (service);
@@ -3353,6 +3358,12 @@
     port = htons ((unsigned short) XINT (service));
   else
     {
+      /* Take a symbol as the service and convert it to a string.  */
+      if (SYMBOLP (service))
+	{
+	  service = Fsymbol_name (service);
+	}
+
       struct servent *svc_info;
       CHECK_STRING (service);
       svc_info = getservbyname (SDATA (service),

Re: Allow specifying services as symbols?

[Stefan Monnier]

>>> As more of a philosophical objection than anything, t is a symbol.
>> Hmm, good catch.  So's nil.
> True.  Perhaps this isn't a good idea after all.  It's just come more
> than a few times over the years that people are using 'nntp instead of
> "nntp" and 'imap instead of "imap" and not understanding why they're
> getting errors.

Maybe signalling a clear error would be a better choice.

> The issue came up as a customization user-side problem and I suggested
> allowing symbols.  Using symbols is consistent with many other Emacs
> facilities (too many to list) that use symbols to enumerate a small set
> of choices.  It makes customization simpler and less error-prone for
> software that uses `make-network-process'.  It doesn't really cost

We're talking about an argument to a function, so it's not directly
related to customization.  IOW if there's a problem with customization,
it can be fixed elsewhere.


        Stefan

Re: Allow specifying services as symbols?

[Chong Yidong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> As more of a philosophical objection than anything, t is a symbol.
>>> Hmm, good catch.  So's nil.
>> True.  Perhaps this isn't a good idea after all.  It's just come more
>> than a few times over the years that people are using 'nntp instead of
>> "nntp" and 'imap instead of "imap" and not understanding why they're
>> getting errors.
>
> Maybe signalling a clear error would be a better choice.

True enough, but

  (make-network-process :service 'http)

does seem a bit more elispy than

  (make-network-process :service "http")

Re: Allow specifying services as symbols?

[Ted Zlatanov]

On Wed, 20 Oct 2010 11:36:00 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> The issue came up as a customization user-side problem and I suggested
>> allowing symbols.  Using symbols is consistent with many other Emacs
>> facilities (too many to list) that use symbols to enumerate a small set
>> of choices.  It makes customization simpler and less error-prone for
>> software that uses `make-network-process'.  It doesn't really cost

SM> We're talking about an argument to a function, so it's not directly
SM> related to customization.  IOW if there's a problem with customization,
SM> it can be fixed elsewhere.

OK, let's forget about the patch.  There's too many useful cases where a
symbol could be passed to `make-network-process' as the service name and
trigger special behavior, plus there's no real need for changing the
current behavior.

Ted