<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Thanks for the support, Phoe. <br>
<br>
From the technological context of early CL history, I do sort-of
"get" some of the thinking behind method dispatch limitations. (Too
bad Gregor isn't here to speak for himself). At the time, Common
Lisp proponents were deathly afraid of Lisp's reputation as a "slow
language," so it is unclear that CL being originally designed in the
<i>absence</i> of CLOS is to blame. I suppose it is interesting
that, at least in my circles, performance declarations never caught
on (e.g. speed 3, safety 0). In my professional work, I have been
known to seek out and destroy such monsters in every library we use.<br>
<br>
--Tim<br>
<br>
<div class="moz-cite-prefix">On 1/5/24 8:44 AM, Michał "phoe" Herda
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7df5a541-d7c6-46e9-aa85-4a8fbddc1b3c@disroot.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>I'm not arguing that it shouldn't be in CL, I'm arguing that
it's not there because no one has done it. I guess you're free
to extend CCL with the functionality you're proposing, i.e. by
introducing a new method specializer in addition to the current
class and EQL specialization.</p>
<p>Once a single working implementation is there, it's much easier
to convince other implementations to add it and end up turning
it into a de-facto standard (like with package-local nicknames).<br>
</p>
<div class="moz-cite-prefix">On 5.01.2024 14:41, Tim McNerney
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b7452342-3a8e-4184-8e66-634a5393011c@media.mit.edu">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
To which, (at the risk of a civilized flame war), I say, "too
bad."<br>
IMHO, this was a short-sighted and poor design decision by the
X3J13 committee, <i>et al</i>.<br>
The same debate came up within the greater Java community, <br>
and it is one place where Java and C# diverged.<br>
Java's designers made similar choices to Common Lisp's: <br>
two kinds of datatypes, dispatchable objects and everything
else.<br>
C# is arguably "Java done right," where <i>everything</i> is a
dispatchable "object."<br>
<br>
There are clear benefits: it would also result in a cleaner,
more appealing, more powerful language.<br>
It's not too late to fix this flaw. What's the harm? <br>
The "non-object" dispatch code would only be present in generic
functions when necessary.<br>
<br>
--Tim<br>
<br>
<div class="moz-cite-prefix">On 1/2/24 6:17 AM, Michał "phoe"
Herda wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5a6500c0585e1ab4a1eb0530ee655fbf@disroot.org">
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<p>No, standard CLOS dispatch happens only on classes.</p>
<p>Have you tried <a
href="https://github.com/digikar99/polymorphic-functions"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/digikar99/polymorphic-functions</a>
?</p>
<p id="reply-intro">W dniu 2024-01-02 12:14, Taoufik Dachraoui
napisał(a):</p>
<blockquote type="cite"
style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div dir="ltr">Hi
<div> </div>
<div>I am trying to use '(simple-vector n) as type
specifier in defmethod but it is not possible, is
there another way?<br>
<br>
(typep #(1 2 3 4) '(simple-vector 4))<br>
<br>
(defmethod mul ((n fixnum) (m1 (simple-vector n)) (m2
(simple-vector n)))<br>
(let ((r (make-array (list n))))<br>
(dotimes (i n)<br>
(setf (svref r i) (* (svref m1 i) (svref m2
i))))<br>
r))<br>
<div> </div>
Kind regards<br>
<div class="v1gmail_signature" dir="ltr">
<div dir="ltr">Taoufik Dachraoui
<div> </div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<p><br>
</p>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>