typechecking

typechecking

[Han-Wen Nienhuys]

I've added the stricter typechecking code to the SCM_UNPACK macro in
CVS HEAD. It caught a few glitches in goops.h and backtrace.h , which
I corrected.  I propose that the old

  DEBUG_TYPING_STRICTNESS==2

is removed, as it provides little extra strictness.

Also, I think that DEBUG_TYPING_STRICTNESS==0 should go too. The code
contained a thinko (leading to loads of compile errors).  This
suggests that the code has never been tested since its inception a few
years ago.



-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Marius Vollmer]

Han-Wen Nienhuys  <hanwen@xs4all.nl> writes:

> I've added the stricter typechecking code to the SCM_UNPACK macro in
> CVS HEAD. It caught a few glitches in goops.h and backtrace.h , which
> I corrected.

Thanks!

> I propose that the old
>
>   DEBUG_TYPING_STRICTNESS==2
>
> is removed, as it provides little extra strictness.

Hmm, I don't agree.  That setting is much stricter than the default
one: Guile itself has many places that would need to be fixed for
STRICTNESS == 2.  For example, code like

    SCM x;

    if (x == SCM_EOL)
      ...

does not compile with STRICTNESS == 2, and it is indeed not completely
correct.  (It should be SCM_EQ_P (x, SCM_EOL) or SCM_NULLP (x).)

It would be a nice little (?) project to make Guile compile with
STRICTNESS == 2.  Some places, like 

    switch (ISYMNUM (SCM_CAR (x)))
      {
      case (ISYMNUM (SCM_IM_AND)):

in eval.c might be hard to fix, tho.

> Also, I think that DEBUG_TYPING_STRICTNESS==0 should go too. The code
> contained a thinko (leading to loads of compile errors).  This
> suggests that the code has never been tested since its inception a few
> years ago.

Can you elaborate?  Guile itself compiles fine with STRICTNESS==0.
Indeed, this strictness level offers no type checking.


When I say "type checking" what really mean is that the compiler
checks whether the user only uses SCM values in the way we want it to,
like, no direct arithmetic, no direct use in conditional tests, only
direct assignment.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Dale P. Smith]

Marius Vollmer <mvo@zagadka.de> writes:

> Han-Wen Nienhuys  <hanwen@xs4all.nl> writes:
>> I propose that the old
>>
>>   DEBUG_TYPING_STRICTNESS==2
>>
>> is removed, as it provides little extra strictness.
>
> Hmm, I don't agree.  That setting is much stricter than the default
> one: Guile itself has many places that would need to be fixed for
> STRICTNESS == 2.  For example, code like
>
>     SCM x;
>
>     if (x == SCM_EOL)
>       ...
>
> does not compile with STRICTNESS == 2, and it is indeed not completely
> correct.  (It should be SCM_EQ_P (x, SCM_EOL) or SCM_NULLP (x).)
>
> It would be a nice little (?) project to make Guile compile with
> STRICTNESS == 2.  Some places, like 
>
>     switch (ISYMNUM (SCM_CAR (x)))
>       {
>       case (ISYMNUM (SCM_IM_AND)):
>
> in eval.c might be hard to fix, tho.

I thought that STRICTNESS == 2 was for extreme type checking, but for
suboptimal code, and that Guile code should always be able to be
compiled at level 2.

-Dale

-- 
Dale P. Smith
dsmith at actron dot com


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Han-Wen Nienhuys]

mvo@zagadka.de writes:
> 
> in eval.c might be hard to fix, tho.
> 
> > Also, I think that DEBUG_TYPING_STRICTNESS==0 should go too. The code
> > contained a thinko (leading to loads of compile errors).  This
> > suggests that the code has never been tested since its inception a few
> > years ago.
> 
> Can you elaborate?  Guile itself compiles fine with STRICTNESS==0.
> Indeed, this strictness level offers no type checking.

1.6.4 has

  #   define SCM_PACK(x) ((scm_t_bits) (x))

I believe this should be

  #define SCM_PACK(x) ((SCM) (x))

if anything.

> When I say "type checking" what really mean is that the compiler
> checks whether the user only uses SCM values in the way we want it to,
> like, no direct arithmetic, no direct use in conditional tests, only

What's the rationale for not allowing direct use in conditional tests?


-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Dirk Herrmann]

Han-Wen Nienhuys wrote:

>  mvo@zagadka.de writes:
>
> > When I say "type checking" what really mean is that the compiler
> > checks whether the user only uses SCM values in the way we want it
> > to, like, no direct arithmetic, no direct use in conditional tests,
> > only
>
>  What's the rationale for not allowing direct use in conditional
>  tests?

Code like the following:

void f (SCM obj)
{
  if (obj) {
    /* do something */
  }
}

is almost always wrong, since what the user typically wants to check is, 
whether obj is SCM_BOOL_F or not:

void f (SCM obj)
{
  if (!SCM_FALSEP (obj)) {
    /* do something */
  }
}

The first version, however, will compile if SCM is defined to be some 
pointer type.

Best regards,
Dirk Herrmann




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Han-Wen Nienhuys]

dirk@dirk-herrmanns-seiten.de writes:
> Han-Wen Nienhuys wrote:
> 
> >  mvo@zagadka.de writes:
> >
> > > When I say "type checking" what really mean is that the compiler
> > > checks whether the user only uses SCM values in the way we want it
> > > to, like, no direct arithmetic, no direct use in conditional tests,
> > > only
> >
> >  What's the rationale for not allowing direct use in conditional
> >  tests?
> 
> Code like the following:
> 

that doesn't really answer my question. It seems to me that

  if (obj == gh_symbol2scm("bla"))
    ...

is safe. Do I understand correctly that disallowing this is a side
effect of trying to disallow

  if (obj)
    ...

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> that doesn't really answer my question. It seems to me that
>
>   if (obj == gh_symbol2scm("bla"))
>     ...
>
> is safe.

It does currently work, and will likely continue to work for a very
long time.  (Even with the strange nil/#f/() tryptich planned for
getting Elisp into Guile.)  However, for a proper abstract data type
like SCM, it would be cleaner to use SCM_EQ_P.  Setting
DEBUG_TYPE_STRICTNESS to 2 will not allow direct comparisons.

> Do I understand correctly that disallowing this is a side
> effect of trying to disallow
>
>   if (obj)
>     ...

No, I don't think so.  The two cases seem very different to me.  "if
(obj)" will never be correct since the SCM encoding that is considered
false by C will never occur, and more importantly, SCM_BOOL_F is not
false when seen directy by C.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Han-Wen Nienhuys]

dirk@dirk-herrmanns-seiten.de writes:
> >
> >  What's the rationale for not allowing direct use in conditional
> >  tests?
> 
> Code like the following:
> 
> void f (SCM obj)
> {
>   if (obj) {
>     /* do something */
>   }
> }
> 
> is almost always wrong, since what the user typically wants to check is, 
> whether obj is SCM_BOOL_F or not:

It would be interesting to see if we could map the Scheme semantics
(true = !SCM_BOOL_F) to C. That would require mapping SCM_BOOL_F to
(void*)0x0. Is this desirable, and does anyone see a possibility for this?


-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Han-Wen Nienhuys]

dirk@dirk-herrmanns-seiten.de writes:
> >>    
> >>
> >
> >It would be interesting to see if we could map the Scheme semantics
> >(true = !SCM_BOOL_F) to C. That would require mapping SCM_BOOL_F to
> >(void*)0x0. Is this desirable, and does anyone see a possibility for this?
> >
> SCM values, where the 3 least significant bits are zero indicate 
> non-immediates. That is, the SCM value can without any modification be 

I understand the tag system, so I'm aware of the
implications. However, I was wondering whether such a change stands a
chance of being incorporated, if it would work.

-- 

 Han-Wen Nienhuys   |   hanwen@xs4all.nl   |   http://www.xs4all.nl/~hanwen 



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Dirk Herrmann]

Han-Wen Nienhuys wrote:

>dirk@dirk-herrmanns-seiten.de writes:
>  
>
>>Code like the following:
>>
>>void f (SCM obj)
>>{
>>  if (obj) {
>>    /* do something */
>>  }
>>}
>>
>>is almost always wrong, since what the user typically wants to check is, 
>>whether obj is SCM_BOOL_F or not:
>>    
>>
>
>It would be interesting to see if we could map the Scheme semantics
>(true = !SCM_BOOL_F) to C. That would require mapping SCM_BOOL_F to
>(void*)0x0. Is this desirable, and does anyone see a possibility for this?
>
SCM values, where the 3 least significant bits are zero indicate 
non-immediates. That is, the SCM value can without any modification be 
used as a pointer to a scm_t_cell object on the heap. This works, since 
scm_t_cell has at least 8 bytes and thus the heap is constructed such 
that all scm_t_cell objects are placed on an address that is a multiple 
of 8.

SCM_BOOL_F on the contrary is an immediate value. To make SCM_BOOL_F == 
0x00 would require either to introduce it as a special case and leave 
otherwise the definitions of non-immediates the same, or to change the 
type system such that non-immediates are characterised differently. Both 
solutions, however, would require to perform some operation on every 
access to the heap. On the contrary, they would make all comparisons 
against SCM_BOOL_F very simple and also help to avoid some errors.

The effects of such a change are difficult to predict. It may be that it 
is not too much effort to try it out (at least the special case 
solution), if everywhere the correct access macros are used (SCM_IMP, 
SCM_FALSEP, ...).  Then, for a try you would only have to change those.

Best regards
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Andy Wingo]

On Wed, 2004-05-26 at 19:40 +0200, Han-Wen Nienhuys wrote:

> It would be interesting to see if we could map the Scheme semantics
> (true = !SCM_BOOL_F) to C. That would require mapping SCM_BOOL_F to
> (void*)0x0. Is this desirable, and does anyone see a possibility for this?

I've been caught by this error a few times, and the scheme true/false
semantics do map nicely to C.

Howeverm the idea has some problems. For one, I don't think passing a
union to `if' (which is what SCM is in SCM_DEBUG_TYPING_STRICTNESS==2)
works.

Secondly, I might be bit-stupid, but after about five minutes of
looking, I can't find a nice set of tc3 type tags having #f==0 for which
a fast SCM_IMP can be defined. This hints that trying to do #f==0 is a
bad idea because it constrains the implementation.

Dunno, just my cent-and-a-half.
-- 
Andy Wingo <wingo@pobox.com>


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Dirk Herrmann]

Han-Wen Nienhuys wrote:

>  I understand the tag system, so I'm aware of the implications. [...]

Sure you do. Sorry if this sounded if I thought you didn't. I am always
somewhat verbose when mailing to the list, even when mailing to guile-devel:
I try to make it possible for many people to follow the discussion. And
guile-devel, to my knowledge, is open for everyone interested.

Sorry again for not making this clear in my post.

>  However, I was wondering whether such a change stands a chance of
>  being incorporated, if it would work.

I think this can't be answered before actually having tried it out and 
knowing
about whether it brings any benefit. Trying it out, however, would bring 
some
benefit itself: It would help to identify places in guile, where code 
circumvents
using the low-level access macros and allow to bring guile to a state where
such experiments would be easier in the future.

Best regards
Dirk



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Marius Vollmer]

dsmith@actron.com (Dale P. Smith) writes:

> I thought that STRICTNESS == 2 was for extreme type checking, but for
> suboptimal code, and that Guile code should always be able to be
> compiled at level 2.

Yeah, in an ideal world... :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: typechecking

[Marius Vollmer]

Han-Wen Nienhuys <hanwen@xs4all.nl> writes:

> dirk@dirk-herrmanns-seiten.de writes:
>> >>    
>> >>
>> >
>> >It would be interesting to see if we could map the Scheme semantics
>> >(true = !SCM_BOOL_F) to C. That would require mapping SCM_BOOL_F to
>> >(void*)0x0. Is this desirable, and does anyone see a possibility for this?
>> >
>> SCM values, where the 3 least significant bits are zero indicate 
>> non-immediates. That is, the SCM value can without any modification be 
>
> I understand the tag system, so I'm aware of the
> implications. However, I was wondering whether such a change stands a
> chance of being incorporated, if it would work.

I find it quite tempting to make SCM_BOOL_F identical to 0; it will
prevent a lot of bugs.  But I do think it is better to not gurantee
anything like this about the SCM type (except that you can assign it
directly).

A properly abstract interface to SCM values is a good thing, even if
it is inconvenient at times.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel