CLISP - an ANSI Common Lisp

Bruno Haible wrote:
> 
> Update of /cvsroot/clisp/clisp/src
> In directory slayer.i.sourceforge.net:/tmp/cvs-serv15786
> 
> Modified Files:
>         ChangeLog stream.d
> Log Message:
> Fix the last patch to stream-element-type.

this patch fails with

stream.d: In function `C_built_in_stream_element_type':
stream.d:16535: structure has no member named `S_stream_element_type'

as is and with

Undefined                       first referenced
 symbol                             in file
C_stream_element_type               spvwtabf.o
ld: fatal: Symbol referencing errors. No output written to lisp.run
collect2: ld returned 1 exit status
ld: Software Generation Utilities - Solaris/ELF (3.0)
Undefined                       first referenced
 symbol                             in file
C_stream_element_type               spvwtabf.o
ld: fatal: Symbol referencing errors. No output written to lisp.run

when I add the appropriate lines in subr.d and constsym.d

Sam writes:

> this patch fails with
> 
> stream.d: In function `C_built_in_stream_element_type':
> stream.d:16535: structure has no member named `S_stream_element_type'

Oh. You can see my patch was untested. I've fixed it now.

> Undefined                       first referenced
>  symbol                             in file
> C_stream_element_type               spvwtabf.o
> ld: fatal: Symbol referencing errors. No output written to lisp.run
> 
> when I add the appropriate lines in subr.d and constsym.d

Why would you want to add it to subr.d? The function is defined in
gstream.lisp. It's not a SUBR.

Bruno

Bruno Haible wrote:
> 
> Sam writes:
> 
> > this patch fails with
> >
> > stream.d: In function `C_built_in_stream_element_type':
> > stream.d:16535: structure has no member named `S_stream_element_type'
> 
> Oh. You can see my patch was untested.

Aha! I am not the only one checking in untested patches! :-)

> I've fixed it now.

not quite: a simple juggling can easily yield

(setq a (open "/tmp/z" :direction :io :element-type (list 'unsigned-byte
16))
      b (open "/tmp/z" :direction :io :element-type (list 'signed-byte
8))
      c (open "/tmp/z" :direction :io :element-type (list 'signed-byte
8))
      d (make-string-output-stream) 
      e (make-two-way-stream a b)
      f (make-two-way-stream c d)
      g (make-two-way-stream e f))

(stream-element-type g)
(OR (UNSIGNED-BYTE 16) (SIGNED-BYTE 8) (SIGNED-BYTE 8) CHARACTER)

you can see (signed-byte 8) there twice.

I will write `type-eq', as we discussed in private, and put it into
type.lisp
(and pass it as :test to remove-duplicates)

Sam writes:

> (stream-element-type g)
> (OR (UNSIGNED-BYTE 16) (SIGNED-BYTE 8) (SIGNED-BYTE 8) CHARACTER)
> 
> you can see (signed-byte 8) there twice.

Which is not a bug.

> I will write `type-eq', as we discussed in private, and put it into
> type.lisp
> (and pass it as :test to remove-duplicates)

That's one possible optimization. Another approach is to write a general
`simplify-type' function, which would return
  (OR (INTEGER -256 65535) CHARACTER)

Bruno

>>>>> "Bruno" == Bruno Haible <haible@...> writes:

    Bruno> Sam writes:
    >> (stream-element-type g)
    >> (OR (UNSIGNED-BYTE 16) (SIGNED-BYTE 8) (SIGNED-BYTE 8) CHARACTER)
    >> 
    >> you can see (signed-byte 8) there twice.

    Bruno> Which is not a bug.

    >> I will write `type-eq', as we discussed in private, and put it into
    >> type.lisp
    >> (and pass it as :test to remove-duplicates)

    Bruno> That's one possible optimization. Another approach is to write a general
    Bruno> `simplify-type' function, which would return
    Bruno>   (OR (INTEGER -256 65535) CHARACTER)

I hope simplify-type function doesn't actually say this! :-)

It should return (or (integer -128 65535) character).

Ray

Raymond Toy writes:

> It should return (or (integer -128 65535) character).

Of course :-) Thanks.

Bruno

Bruno Haible wrote:
> 
> Sam writes:
> 
> > (stream-element-type g)
> > (OR (UNSIGNED-BYTE 16) (SIGNED-BYTE 8) (SIGNED-BYTE 8) CHARACTER)
> >
> > you can see (signed-byte 8) there twice.
> Which is not a bug.

true, but it's as ugly as it gets.

> > I will write `type-eq', as we discussed in private, and put it into
> > type.lisp
> > (and pass it as :test to remove-duplicates)
> 
> That's one possible optimization. Another approach is to write a general
> `simplify-type' function, which would return
>   (OR (INTEGER -256 65535) CHARACTER)

I would think that canonicalize-type should do this.
it's non-recursive now, making it recursive for OR and AND would be a
huge step forward.

Sam writes:

> > > I will write `type-eq', as we discussed in private, and put it into
> > > type.lisp
> > > (and pass it as :test to remove-duplicates)
> > 
> > That's one possible optimization. Another approach is to write a general
> > `simplify-type' function, which would return
> >   (OR (INTEGER -256 65535) CHARACTER)
> 
> I would think that canonicalize-type should do this.
> it's non-recursive now, making it recursive for OR and AND would be a
> huge step forward.

canonicalize-type is only used by SUBTYPEP. Modifying canonicalize-type as
you point out would only make it slower, in many cases, for example

  (subtypep '(unsigned-byte 8) '(or integer extended-char complicated-deftype))

does not need to expand all the parts of the second type in order to return
the correct result.

The ultimate canonicalize-type, if you need one, is described in Henry Baker's
paper gallery.

Bruno

Bruno Haible wrote:
> 
> Sam writes:
> 
> > > > I will write `type-eq', as we discussed in private, and put it into
> > > > type.lisp
> > > > (and pass it as :test to remove-duplicates)
> > >
> > > That's one possible optimization. Another approach is to write a general
> > > `simplify-type' function, which would return
> > >   (OR (INTEGER -256 65535) CHARACTER)
> >
> > I would think that canonicalize-type should do this.
> > it's non-recursive now, making it recursive for OR and AND would be a
> > huge step forward.
> 
> canonicalize-type is only used by SUBTYPEP. Modifying canonicalize-type as
> you point out would only make it slower

okay, so do we want a full-blown simplify-type on top of
canonicalize-type?

> The ultimate canonicalize-type, if you need one, is described in Henry Baker's
> paper gallery.

can't find it there.

Sam writes:

> okay, so do we want a full-blown simplify-type on top of
> canonicalize-type?

Compilers with full type inference will need it. Users can be happy with
TYPE-EXPAND we have. SUBTYPEP doesn't need it.

Btw, how do you imagine that a full-blown simplify-type should treat
infinitely recursive types like

   (deftype proper-list () '(or null (cons t proper-list)))
or
   (deftype valid-typespec ()
     '(or (member nil null fixnum ...)
          (cons (member and or) valid-typespec-list)
          ...))
   (deftype valid-typespec-list ()
     '(or null (cons valid-typespec valid-typespec-list)))
?

The validity of such types was discussed in c.l.l. a while ago, and IIRC,
the majority opinion is that they should be considered to be valid, as
long for any given object x, (typep x type) is computable in finite time.

Bruno

Bruno Haible wrote:
> Btw, how do you imagine that a full-blown simplify-type should treat
> infinitely recursive types like
> 
>    (deftype proper-list () '(or null (cons t proper-list)))
> or
>    (deftype valid-typespec ()
>      '(or (member nil null fixnum ...)
>           (cons (member and or) valid-typespec-list)
>           ...))
>    (deftype valid-typespec-list ()
>      '(or null (cons valid-typespec valid-typespec-list)))
> ?

detect recursion and return (satisfies valid-typespec-list-p),
where valid-typespec-list-p is compiled when deftype is processed.