Re: [Axiom-developer] Re: metalex change

[Stephen Wilson]

Gabriel Dos Reis <address@hidden> writes:

> On Thu, 9 Aug 2007, Stephen Wilson wrote:
> 
> | Gabriel Dos Reis <address@hidden> writes:
> | > Also, if the function expects strings, we should give it a string.
> | 
> | Although not documented as such, it is likely that
> | system:string-concatenate is designed to take string designators as
> | arguments instead of `just' strings.  This is a fairly common Lisp
> | idiom, so I do not see a problem.  Perhaps a close look at the gcl
> | code and a patch against the documentation in si-defs.texi is in
> | order.
> 
> I'm using SBCL to type check the code.  But that should not matter much.
> 
> We have two versions, one that uses GCL's stuff, and one that uses the
> standard concatenate with type 'string.  We should write codes that compile
> with either version.

OK.  I think the function is quite broken anyways.  It should either
be removed and calls go directly to cl::concatenate or we should
define a semantics which makes sense.  Having concat return either a
bit-vector or string depending on the type of the first argument is
just bizarre.

Possibly the only sensible semantics would be to have 'concat require
all its arguments to be of the same type T s.t. (subtype T 'sequence)
returns true, and then just call (concatenate T args).

If optimized versions for a specific type are needed I would suggest
writing them independently as `concat-string', `concat-bit-vec', etc.


Any alternatives?


Steve