Strange behaviour of array?

Strange behaviour of array?

[tomas]

Hi,

while playing around with arrays (see my dumb questions in
guile-user) I stumbled across this:

| guile> (array? #f)
| #f
| guile> (array? 13)
| #f
| guile> (array? 'thisisasymbol)
| #t
| guile> (array? (list 1 2 3 4))
| #t
| guile> (array? 1.5)
| #f
| guile> (array? 3/4)
| #f
| guile> (array? +)
| #t
| guile> (array? 13228374653846507238652384)
| #f

It seems that many non-immediate values returns #t on array?. Looking
at the source (libguile/unif.c, around line 280) kind of semi-confirms
this (as far as I understand this tagging business).

This is against guile 1.6.0 as released (I haven't the time to check
now against CVS for lack of a suitable autoconf :-(

Regards
-- tomas


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

Re: Strange behaviour of array?

[Christopher Cramer]

On Tue, Nov 05, 2002 at 12:57:06PM +0100, tomas@fabula.de wrote:
> It seems that many non-immediate values returns #t on array?. Looking
> at the source (libguile/unif.c, around line 280) kind of semi-confirms
> this (as far as I understand this tagging business).
> 
> This is against guile 1.6.0 as released (I haven't the time to check
> now against CVS for lack of a suitable autoconf :-(

I distinctly remember sending a patch to fix this to either bug-guile or
guile-devel a loooong time ago, but I can't find it in the archives. I'm
surprised it's not fixed in 1.6.0, but maybe it's because I never sent
the patch in...

Index: libguile/unif.c
===================================================================
RCS file: /cvsroot/guile/guile/guile-core/libguile/unif.c,v
retrieving revision 1.120.2.5
diff -u -r1.120.2.5 unif.c
--- libguile/unif.c	22 Feb 2002 23:04:15 -0000	1.120.2.5
+++ libguile/unif.c	13 Mar 2002 00:57:19 -0000
@@ -295,7 +295,7 @@
   int enclosed;
   nprot = SCM_UNBNDP (prot);
   enclosed = 0;
-  if (SCM_IMP (v))
+  if (SCM_IMP (v) || (!SCM_ARRAYP(v) && !SCM_VECTORP(v)))
     return SCM_BOOL_F;
 
   while (SCM_TYP7 (v) == scm_tc7_smob)
@@ -309,7 +309,7 @@
       v = SCM_ARRAY_V (v);
      }
   if (nprot)
-    return SCM_BOOL(nprot);
+    return SCM_BOOL_T;
   else
     {
       int protp = 0;

-- 
Christopher Cramer <crayc@pyro.net> <http://www.pyro.net/~crayc/>
"Gore would have finished ahead by the barest of margins had he pursued
and gained a complete statewide recount." -- Associated Press, 9/6/2002


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

Re: Strange behaviour of array?

[tomas]

On Fri, Nov 15, 2002 at 02:12:13AM -0600, Christopher Cramer wrote:
> On Tue, Nov 05, 2002 at 12:57:06PM +0100, tomas@fabula.de wrote:
[...]
> I distinctly remember sending a patch to fix this to either bug-guile or
> guile-devel a loooong time ago, but I can't find it in the archives. I'm
> surprised it's not fixed in 1.6.0, but maybe it's because I never sent
> the patch in...

Thanks a zillion. I'll try this out when out of crunch mode.
I'll keep you informed

Regards
-- tomas


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

Re: Strange behaviour of array?

[Marius Vollmer]

Christopher Cramer <crayc@pyro.net> writes:

> I distinctly remember sending a patch to fix this to either bug-guile or
> guile-devel a loooong time ago, but I can't find it in the archives. I'm
> surprised it's not fixed in 1.6.0, but maybe it's because I never sent
> the patch in...

I'm hesitant to just apply this patch.  The 'array' stuff in Guile is
quite obscure, in my view, and fixing it piecewise does not seem to be
a good idea, given its (appearant) brittleness.  For example, with
your patch,

  guile> (array? "foo")
  #f

but

  guile> (array-ref "foo" 0)
  #\f

which is inconsistent.  On the other hand, we have now

  guile> (array? 'foo)
  #t

but

  guile> (array-ref 'foo 0)
  Wrong type argument in position 1: foo

which is also inconsistent.

The whole array stuff needs to be looked over, with SRFI-4 in mind.

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


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