Re: featurep

Re: featurep

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> I agree with the people who say this is not very clean:
> 
>   The following special call returns t iff a given KEY VALUE
>   pair is supported on this system:
> !   (make-network-process :feature KEY VALUE)
> 
> Couldn't this be done with featurep, using sub-features?
> Please try to design it that way.

I agree that it would be cleaner (in a purist sense) to have this work
through featurep, and technically there is nothing (serious) preventing
this from working.

However, for a usage point of view, I don't really see why it
matters, and IMHO, using featurep will be _less_ intuitive.
For example, I think using

  (if (and (make-network-process :feature :family 'local)
           (make-network-process :feature :datagram t))
        
to test whether make-network-process supports datagrams and the local
sockets is a lot easier to use (since those are the exact same
arguments which are used to select those features) than to test on
some similar, but not quite the same, symbols like

  (if (and (featurep 'networking 'local-sockets)
           (featurep 'networking 'datagrams))

To take this further, you can test whether a give socket option
is supported (without adding extra code at the C-level) with

  (if (make-network-process :feature :options 'oobinline)

whereas doing the same with featurep requires adding more
symbols and code to be able to say something like

  (if (featurep 'networking 'oobinline-option)

In fact, what you are asking is that I invent slightly different names
for all the various combinations of arguments to make-network-process,
just for the purpose of being able to use a standard way to test for
the availablility of those features.

Actually, if you accept to leave in the :featurep argument,
it would be possible to do this at the lisp level using code
like this:

  (let ((subfeatures nil))
     (if (make-network-process :featurep :datagram t)
        (setq subfeatures (cons 'datagrams subfeatures)))
     (if (make-network-process :featurep :family local)
        (setq subfeatures (cons 'local-sockets subfeatures)))
     (if (make-network-process :featurep :options 'oobinline)
        (setq subfeatures (cons 'oobinline-option subfeatures)))
     ;; etc...
     (provide 'networking subfeatures))
     

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Jason Rumney]

storm@cua.dk (Kim F. Storm) writes:

> However, for a usage point of view, I don't really see why it
> matters, and IMHO, using featurep will be _less_ intuitive.
> For example, I think using
> 
>   (if (and (make-network-process :feature :family 'local)
>            (make-network-process :feature :datagram t))

Having make-network-process doing something other than making a
network process is not a more intuitive solution than featurep.


-- 
Jason Rumney


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Stefan Monnier]

> storm@cua.dk (Kim F. Storm) writes:
> 
> > However, for a usage point of view, I don't really see why it
> > matters, and IMHO, using featurep will be _less_ intuitive.
> > For example, I think using
> > 
> >   (if (and (make-network-process :feature :family 'local)
> >            (make-network-process :feature :datagram t))
> 
> Having make-network-process doing something other than making a
> network process is not a more intuitive solution than featurep.

Agreed.  I also agree that `featurep' is not a perfect answer, tho.
Ideally, what I'd like is something like

	(featuredp '(make-network-process :family 'local))

where `featuredp' simply takes a function together with a set of
arguments and returns whether or not that call is "supported".
It would first check the fboundness of the function, the number of arguments
and all those things.

But I have no good idea how to go about implementing this thing, so
as a first step, I think that it should be good enough just to make
`make-network-process' fail when called with arguments requiring
unsupported features.  After all, it's generally the case that if
the feature is supported, then we do want to make the function call,
so we might as well call the function and see if it worked.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > storm@cua.dk (Kim F. Storm) writes:
> > 
> > > However, for a usage point of view, I don't really see why it
> > > matters, and IMHO, using featurep will be _less_ intuitive.
> > > For example, I think using
> > > 
> > >   (if (and (make-network-process :feature :family 'local)
> > >            (make-network-process :feature :datagram t))
> > 
> > Having make-network-process doing something other than making a
> > network process is not a more intuitive solution than featurep.
> 
> Agreed.  I also agree that `featurep' is not a perfect answer, tho.
> Ideally, what I'd like is something like
> 
> 	(featuredp '(make-network-process :family 'local))
> 
> where `featuredp' simply takes a function together with a set of
> arguments and returns whether or not that call is "supported".
> It would first check the fboundness of the function, the number of arguments
> and all those things.

I think this would be overkill.  If we go that route, then it should
apply to all functions - and that has never been the intention.

> 
> But I have no good idea how to go about implementing this thing, so
> as a first step, I think that it should be good enough just to make
> `make-network-process' fail when called with arguments requiring
> unsupported features.  After all, it's generally the case that if
> the feature is supported, then we do want to make the function call,
> so we might as well call the function and see if it worked.

Ok, but if you combine :family 'local and :datagram t, and
make-network-process returns nil, you really don't know whether it's
because it doesn't support local sockets or datagrams -- so what would
you try next?

In any case, I disagree, but I don't want to be religious about this,
so I'll change the code to use featurep.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Stefan Monnier]

> > where `featuredp' simply takes a function together with a set of
> > arguments and returns whether or not that call is "supported".
> > It would first check the fboundness of the function, the number of arguments
> > and all those things.
> 
> I think this would be overkill.  If we go that route, then it should
> apply to all functions

Yes, that was my intention.

> and that has never been the intention.

No, indeed, I understand that it is way past any immediate concern
and as I said, I have no clue how to implement such a thing.

> > But I have no good idea how to go about implementing this thing, so
> > as a first step, I think that it should be good enough just to make
> > `make-network-process' fail when called with arguments requiring
> > unsupported features.  After all, it's generally the case that if
> > the feature is supported, then we do want to make the function call,
> > so we might as well call the function and see if it worked.
> 
> Ok, but if you combine :family 'local and :datagram t, and
> make-network-process returns nil, you really don't know whether it's
> because it doesn't support local sockets or datagrams -- so what would
> you try next?

Why does it matter ?
What would the code look like using your :feature thing ?
Most likely your code can handle a small fixed number of different
combination of features.  It can use :feature to decide which one
of the alternatives to choose or it can just try them in order
until one of them succeeds.
I.e. I don't see how the "what would you try next" question is relevant
since the problem also shows up with :feature.

> In any case, I disagree, but I don't want to be religious about this,
> so I'll change the code to use featurep.

Is it even necessary ?
I expect that "try-it-and-see" will already catch all relevant cases.
I'm really not convinced that we need anything more, so I wouldn't
bother with anything more until there's some evidence that it
is needed.  Of course, maybe you have that evidence, but I haven't seen it.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > Ok, but if you combine :family 'local and :datagram t, and
> > make-network-process returns nil, you really don't know whether it's
> > because it doesn't support local sockets or datagrams -- so what would
> > you try next?
> 
> Why does it matter ?
> What would the code look like using your :feature thing ?

Probably not a lot different, but without checking for a feature
first, the current code will throw an error for an unsupported feature
indicating (in clear text) what the problem is.

Suppose you write a package using datagrams, and don't handle the case
where it returns nil (as you suggest).  In that case, a user of your
package will just see things not working (which he can report to you
as "it doesn't work"), rather than make-network-process throwing a
"datagrams not supported" error (which will probably give you a better
understanding of the problem when he reports that to you).


> Most likely your code can handle a small fixed number of different
> combination of features.  It can use :feature to decide which one
> of the alternatives to choose or it can just try them in order
> until one of them succeeds.
> I.e. I don't see how the "what would you try next" question is relevant
> since the problem also shows up with :feature.

No, but I disagree with the return nil and try next approach.

> 
> > In any case, I disagree, but I don't want to be religious about this,
> > so I'll change the code to use featurep.
> 
> Is it even necessary ?
> I expect that "try-it-and-see" will already catch all relevant cases.

So, yes, if you as a package author is aware of the possibility that
make-network-process returns nil on some systems for some combination
of features, than everything's fine.  But if some other package author
isn't aware of this, it can be a hard bargain trying to figure out
what went wrong (as the author and the user obviously are not on the
same platform).

> I'm really not convinced that we need anything more, so I wouldn't
> bother with anything more until there's some evidence that it
> is needed.  Of course, maybe you have that evidence, but I haven't seen it.

IMO, being such a multi-facetted beast, make-network-process should
throw exceptions when an unsupported feature is used.  If it didn't
do that, debugging code using it would be difficult.  Your proposal
takes that away (to remove a useful, but unclean :feature :-).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > > Ok, but if you combine :family 'local and :datagram t, and
> > > make-network-process returns nil, you really don't know whether it's
> > > because it doesn't support local sockets or datagrams -- so what would
> > > you try next?
> > 
> > Why does it matter ?
> > What would the code look like using your :feature thing ?
> 
> Probably not a lot different, but without checking for a feature
> first, the current code will throw an error for an unsupported feature
> indicating (in clear text) what the problem is.

That's perfectly fine.  I never actually suggested to rely on a `nil'
return value.  I definitely prefer signalling an error, just make
sure that you use a signal that makes the problem clear like
`unsupported-network-feature' so that the signal handler can
distinguish it from other problems.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > However, for a usage point of view, I don't really see why it
> > matters, and IMHO, using featurep will be _less_ intuitive.
> > For example, I think using
> > 
> >   (if (and (make-network-process :feature :family 'local)
> >            (make-network-process :feature :datagram t))
> 
> Having make-network-process doing something other than making a
> network process is not a more intuitive solution than featurep.

Not but there are fewer things (almost none in fact) to document.
Compare

  (if (make-network-process :feature :family 'local)
      (make-network-process ... ...  :family 'local ...))

to

  (if (featurep 'networking 'local-sockets)
      (make-network-process ... ...  :family 'local ...))

That's two different pairs of symbols rather than one and the same.

But I seem to be out-numbered here, so I'll make the change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Richard Stallman]

    Having make-network-process doing something other than making a
    network process is not a more intuitive solution than featurep.

That is exactly what bothers me about it.

Perhaps we can implement use of lists as subfeatures.  Then
(featurep 'make-network-process '(:family local)) could be used
instead of (make-network-process :feature :family 'local).


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Having make-network-process doing something other than making a
>     network process is not a more intuitive solution than featurep.
> 
> That is exactly what bothers me about it.
> 
> Perhaps we can implement use of lists as subfeatures.  Then
> (featurep 'make-network-process '(:family local)) could be used
> instead of (make-network-process :feature :family 'local).

Good idea.  I've done that!

Using featurep has the added bonus of being able to test for
networking support in general with (featurep 'make-network-process).

You can use (get 'make-network-process 'subfeatures) to get a list of
all supported (non-standard) networking features.

I'm don't know whether this is an officially supported way to access
subfeatures (?), but it allows us to enhance e.g. report-emacs-bug to
include the list of supported networking features if you think that
might be interesting.

I didn't include all the standard features, so while
  (featurep 'make-network-process '(:family local))
returns t iff local sockets are supported, testing with
  (featurep 'make-network-process '(:family nil))
returns nil, because the default is always supported, so there
is no reason to (be able to) test for it.  Is that ok?

BTW, I've changed Ffeaturep to use Fmember instead of Fmemq to compare
features, so we can now use all sorts of data (e.g. lists or strings)
as subfeatures.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Richard Stallman]

    I didn't include all the standard features, so while
      (featurep 'make-network-process '(:family local))
    returns t iff local sockets are supported, testing with
      (featurep 'make-network-process '(:family nil))
    returns nil, because the default is always supported, so there
    is no reason to (be able to) test for it.  Is that ok?

That seems reasonable.

    BTW, I've changed Ffeaturep to use Fmember instead of Fmemq to compare
    features, so we can now use all sorts of data (e.g. lists or strings)
    as subfeatures.

Yes, that was essential here.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Stefan Monnier]

>     Having make-network-process doing something other than making a
>     network process is not a more intuitive solution than featurep.
> 
> That is exactly what bothers me about it.
> 
> Perhaps we can implement use of lists as subfeatures.  Then
> (featurep 'make-network-process '(:family local)) could be used
> instead of (make-network-process :feature :family 'local).

I still haven't heard any evidence that

	(condition-case nil
	    (make-network-process foo bar baz)
	  (unsupported-networking-feature
	    ...do..something..else...))

is not enough and that a separate `featurep' support is required.


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> >     Having make-network-process doing something other than making a
> >     network process is not a more intuitive solution than featurep.
> > 
> > That is exactly what bothers me about it.
> > 
> > Perhaps we can implement use of lists as subfeatures.  Then
> > (featurep 'make-network-process '(:family local)) could be used
> > instead of (make-network-process :feature :family 'local).
> 
> I still haven't heard any evidence that
> 
> 	(condition-case nil
> 	    (make-network-process foo bar baz)
> 	  (unsupported-networking-feature
> 	    ...do..something..else...))
> 
> is not enough and that a separate `featurep' support is required.

One example could be that we need to use different sentinels and
filters depending on what features are supported.  Using the
featurep method, we only need to define the sentinel and filter
functions related to the actual method used.

The condition-case approach means that you don't know in advance
what will be the optimal approach.

++kfs


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Stefan Monnier]

> > >     Having make-network-process doing something other than making a
> > >     network process is not a more intuitive solution than featurep.
> > > 
> > > That is exactly what bothers me about it.
> > > 
> > > Perhaps we can implement use of lists as subfeatures.  Then
> > > (featurep 'make-network-process '(:family local)) could be used
> > > instead of (make-network-process :feature :family 'local).
> > 
> > I still haven't heard any evidence that
> > 
> > 	(condition-case nil
> > 	    (make-network-process foo bar baz)
> > 	  (unsupported-networking-feature
> > 	    ...do..something..else...))
> > 
> > is not enough and that a separate `featurep' support is required.
> 
> One example could be that we need to use different sentinels and
> filters depending on what features are supported.  Using the
> featurep method, we only need to define the sentinel and filter
> functions related to the actual method used.
> 
> The condition-case approach means that you don't know in advance
> what will be the optimal approach.

I wasn't asking "can you think of a case where `featurep' would
be useful" but "are there such cases".  And I don't really care
about cases where `featurep' would be marginally more convenient.

For instance, I'm not convinced by your example: conditionally defining
functions is not something I'd advocate anyway (unless you can put them
in different files, but I doubt the sentinels and filters will
be large enough to warrant my-server-nonblocking.el
and myserver-blocking.el) so have both versions of the code defined
is a perfectly acceptable overhead, just as is the overhead of having
a single version of the functions with a dynamic check inside (I expect
that the different versions of the sentinel and filter codes will
be similar enough that there'll be a fair amount of code-sharing
anyway).


	Stefan


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: featurep

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> I wasn't asking "can you think of a case where `featurep' would
> be useful" but "are there such cases".  And I don't really care
> about cases where `featurep' would be marginally more convenient.

I've already changed the code to use featurep as people on this list
requested.  It is clean, it is working, and some users may find it
useful.

So, please, can we stop this discussion, and get on to other work?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel