Anomalous results from is-a? and instance? on current-input-port

Anomalous results from is-a? and instance? on current-input-port

[Alan Grover]

Guile 1.6.4
Linux xxxx 2.6.5-7.145-default #1 Thu Jan 27 09:19:29 UTC 2005 i686 i686 
i386 GNU/Linux
SuSe 9.1

Some instance and class introspection procedures give anomalous results. 
Specifically, they seem to give false when they shouldn't.

My results (from code below, just for current-input-port). Note the #f's":
; from interactive guile
(class #<<class> <soft-input-port> 8087280>
  instance? #f
  (is-a? <soft-input-port>) #f
  class-direct-supers (#<<class> <soft-port> 80872b0> #<<class> 
<input-port> 8084110>)
  (is-a? <input-port>) #t

Results are repeatable if tried in the same interactive interpreter, or 
run from a script. However, I get the following variations:

* Run from a script: (is-a? <soft-input-port>) #t
* Use my .guile: (is-a? <soft-input-port>) #t

A minimal .guile that causes the variation is:
	(use-modules (ice-9 readline))
	(activate-readline)

In another script, a generic function specialized on <input-port> was 
called properly when the argument was (current-input-port). So that 
seems to work as expected.


To reproduce:
(use-modules (oop goops))
(define (a-test x)
(display
(list
'class (class-of x) "\n"
'instance? (instance? x)  "\n"
'(is-a? <soft-input-port>) (is-a? x <soft-input-port>) "\n"
'(is-a? <soft-output-port>) (is-a? x <soft-input-port>) "\n"
'class-direct-supers (class-direct-supers (class-of x)) "\n"
'(is-a? <input-port>) (is-a? x <input-port>) "\n"
'(is-a? <output-port>) (is-a? x <input-port>) "\n"
)))
(a-test (current-input-port))
(a-test (current-output-port))
(a-test (current-error-port))

-- 
Alan Grover
awgrover@mail.msen.com
+1.734.476.0969


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Anomalous results from is-a? and instance? on current-input-port

[Mikael Djurfeldt]

On Tue, 15 Feb 2005 18:39:44 -0500, Alan Grover <awgrover@mail.msen.com> wrote:
> Guile 1.6.4
> Linux xxxx 2.6.5-7.145-default #1 Thu Jan 27 09:19:29 UTC 2005 i686 i686
> i386 GNU/Linux
> SuSe 9.1
> 
> Some instance and class introspection procedures give anomalous results.
> Specifically, they seem to give false when they shouldn't.
> 
> My results (from code below, just for current-input-port). Note the #f's":
> ; from interactive guile
> (class #<<class> <soft-input-port> 8087280>
>   instance? #f
>   (is-a? <soft-input-port>) #f
>   class-direct-supers (#<<class> <soft-port> 80872b0> #<<class>
> <input-port> 8084110>)
>   (is-a? <input-port>) #t
> 
> Results are repeatable if tried in the same interactive interpreter, or
> run from a script. However, I get the following variations:
> 
> * Run from a script: (is-a? <soft-input-port>) #t
> * Use my .guile: (is-a? <soft-input-port>) #t

* instance? should give #f since the port is not a normal GOOPS
instance but rather a built-in datatype.

* the class-direct-supers list looks OK

* (is-a? <input-port>) gives the correct value #t

The only thing anomalous above is that (is-a? x <soft-input-port>)
gives #f in the interpreter.
I can't repeat that in the development version, so it seems specific
to Guile-1.6.4. Can someone else look into that?

Thanks,
M


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Anomalous results from is-a? and instance? on current-input-port

[Alan Grover]

It's confusing to have an "object" with class, superclasses, etc., but 
not be "an instance". Since "class-of" returns a value (the Goops 
class), that implies it is a Goops instance.

What would be the predicate for determining that something is an 
instance of a class, capable of the introspection procedures, works with 
specialization by inheritance, but not a Goops object?

Mikael Djurfeldt wrote:
> On Tue, 15 Feb 2005 18:39:44 -0500, Alan Grover <awgrover@mail.msen.com> wrote:
> 
>>Guile 1.6.4
>>Linux xxxx 2.6.5-7.145-default #1 Thu Jan 27 09:19:29 UTC 2005 i686 i686
>>i386 GNU/Linux
>>SuSe 9.1
>>
>>Some instance and class introspection procedures give anomalous results.
>>Specifically, they seem to give false when they shouldn't.
>>
>>My results (from code below, just for current-input-port). Note the #f's":
>>; from interactive guile
>>(class #<<class> <soft-input-port> 8087280>
>>  instance? #f
>>  (is-a? <soft-input-port>) #f
>>  class-direct-supers (#<<class> <soft-port> 80872b0> #<<class>
>><input-port> 8084110>)
>>  (is-a? <input-port>) #t
>>
>>Results are repeatable if tried in the same interactive interpreter, or
>>run from a script. However, I get the following variations:
>>
>>* Run from a script: (is-a? <soft-input-port>) #t
>>* Use my .guile: (is-a? <soft-input-port>) #t
> 
> 
> * instance? should give #f since the port is not a normal GOOPS
> instance but rather a built-in datatype.
> 
> * the class-direct-supers list looks OK
> 
> * (is-a? <input-port>) gives the correct value #t
> 
> The only thing anomalous above is that (is-a? x <soft-input-port>)
> gives #f in the interpreter.
> I can't repeat that in the development version, so it seems specific
> to Guile-1.6.4. Can someone else look into that?
> 
> Thanks,
> M

-- 
Alan Grover
awgrover@mail.msen.com
+1.734.476.0969


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: Anomalous results from is-a? and instance? on current-input-port

[Mikael Djurfeldt]

On Wed, 16 Feb 2005 06:55:44 -0500, Alan Grover <awgrover@mail.msen.com> wrote:
> It's confusing to have an "object" with class, superclasses, etc., but
> not be "an instance". Since "class-of" returns a value (the Goops
> class), that implies it is a Goops instance.

Well, ideally every item of data would be a true instance, but that is
difficult to achieve. Historically, neither Scheme nor Guile was
object oriented. GOOPS is an add-on. The reason why all data in Guile
has an explicit representation of its type in terms of a class is to
enable specialization of generic functions to the data. I think the
cost in terms of confusion is payed back by the utility.
I know from my own experience that it is extremely limiting not to be
able to specialize generic functions to strings, numbers etc.

> What would be the predicate for determining that something is an
> instance of a class, capable of the introspection procedures, works with
> specialization by inheritance, but not a Goops object?

I'm not aware of any such object. Objects that can be introspected
using GOOPS introspection procedures, such as slot-ref, *are* GOOPS
objects. Instance? would be the predicate to use to test for that. The
only GOOPS:y thing you can do with an input-port is to ask for its
class (which also implies that you can specialize generic functions to
that class). The fact that instance? returns #f informs you that it
isn't a normal GOOPS object, doesn't have slots etc.

M


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile