Re: coerce for arbitrary types

rem642b@xxxxxxxxx (Robert Maas, see http://tinyurl.com/uh3t) writes:

From: Scott Burson <FSet....@xxxxxxxxx>
If I understand the hyperspec correctly, then there is no way to extend
coerce to accept any other result-type than the ones explicetly listed.

Why do you need to do this? This is often a sign of a program being
structured wrong--trying to get too much information out of too few bits.
http://www.nhplace.com/kent/PS/EQUAL.html#two-bit_rule

In fact, the entire article
http://www.nhplace.com/kent/PS/EQUAL.html
in which that rule resides builds up to the relevant point, which is
that in dynamic languages, additional care is required in order to
infer "intent" because the fact of a representation's use is not the
same as the intent of a representation's use, and you can only
dynamically query about the fact of its use, not the intent. This is
not a bug in dynamic languages because it buys additional, much needed
flexibility in other situations. But in the case here, you have to be
careful to either pass more information or not to infer so much information
from what is passed. Sometimes more information means "another argument"
and sometimes it means "a different representation of the data than the
one you're trying to coerce". So, for example:

IMO [not allowing coerce to be extended is] a good idea, because coerce
is already a crock from the start. It is not possible to change something
from the type it was to the type you want to be

This isn't the reason it's a "crock". That's just the reason it has a
bad name. The definition has issues that make it not easily
extendable independent of its name, and those issues derive from the
nature of the language. In brief, COERCE is too short a name and
falsely gives the sense that it is a canonically defined operation
with only one meaning rather than an operation that has several
(perhaps myriad) friends that are all vying for the cool short-name.
If these were domain names, not function names, all the names
coerce.org, coerce.net., coerce.cc, coerce.tv, etc. would all be
bought up and people would be assigning them subtly different
meanings. But when there's no trailing GTLD to remind us, it's easy
to forget that there was a competition in play.

The real problem is that something you can customize needs to be
defined in such a way that it's clear what customizing it would mean.
For historical reasons, COERCE is already messed up because of the NIL
vs () issue [note well: NOT the issue commonly fussed over, which is
the false vs. empty list issue]. The simple case of:

(coerce nil 'string) => ""
(string nil) => "NIL"

illustrates the problem.

The reason this happens by the way is that STRING plainly does not work
on arbitrary sequences, so there's no confusion that STRING is not asking
to operate on sequences. e.g.,

(string #(#\N #\I #\L))
Error: Cannot coerce #(#\N #\I #\L) to type STRING.

So it was deemed necessary that STRING should lean toward seeing NIL as
its name, which was a string. But COERCE does take sequences, and empty
sequences were common and useful. The progression

(coerce '(a b) 'vector)
=> #(A B)

(coerce '(a) 'vector)
=> #(A)

(coerce '() 'vector)
=> #(#\N #\I #\L)

would have been devastating to getting any work done. So COERCE was defined
to treat NIL as () rather than as a symbol.

In effect, you are meant to make the choice between STRING and
(COERCE x 'STRING) somewhat on the basis of understanding how you want this
particular tie to be broken.

But if we were to make it open season on extending this, in the present of
a dynamic language with multiple inheritance, this kind of problem would
happen all the time, and the result would be ragged... absent the intent
information I alluded to above.
.

Relevant Pages

  • Re: coerce for arbitrary types
    ... coerce to accept any other result-type than the ones explicetly listed. ... to infer "intent" because the fact of a representation's use is not ... different things depending on the intention of the programmer as ... parsing from a string, and no further processing was done after ...
    (comp.lang.lisp)
  • Re: Another VBA bug
    ... string, which it does however surprising at first it may seem. ... Dim dbl As Double ... ' can coerce but can't evaluate ... In Integer Division, if A and/or B are floating point numbers, ...
    (microsoft.public.excel.programming)
  • Re: Another VBA bug
    ... to your Format example, ie an exact .5 always rounds up. ... rather coerce to a valid number. ... string, which it does however surprising at first it may seem. ... dbl = CDate' OK' ...
    (microsoft.public.excel.programming)
  • Re: Another VBA bug
    ... string, which it does however surprising at first it may seem. ... dbl = CDate' OK' ... 'can only coerce to variable declared 'As Date' ... Using CDbl specifically casts 's' as a Double before the assignment is made. ...
    (microsoft.public.excel.programming)
  • Re: Another VBA bug
    ... d = s ' try to coerce ... Function IsDigitsOnly(Value As String) As Boolean ... ' Get local setting for decimal point ...
    (microsoft.public.excel.programming)