Hi everybody!
With the code at the end of this mail I would have expected an outcome
similar to this one
R: T , E: T - [REFUSED TO PRINT]
R: T , E: NIL - [REFUSED TO PRINT]
R: NIL, E: T - #
R: NIL, E: NIL - My condition occured.
because the standard says that "if *PRINT-READABLY* i
Thomas,
That was the piece of the puzzle I had missed.
Thanks,
Edi.
On Sat, Aug 29, 2015 at 12:04 PM, Thomas Burdick wrote:
> Hi Edi,
>
> That certainly reads to me as though the intent is for print-object to be
> the decision point (at least in cases where *print-pretty* is false).
>
> Howe
The following "works" in three different CL implementations I tried
while in three others the way complex numbers are printed doesn't
change.
? (defmethod print-object ((obj complex) stream)
(format stream "#< ~A + ~A * I >"
(realpart obj) (imagpart obj)))
#
? #c(1 1)
#< 1 + 1
On Tue, Jul 21, 2015 at 10:30 AM, Didier Verna wrote:
> http://www.didierverna.net/blog/index.php?post/2013/08/16/Lisp-Corner-Cases%3A-Method-Combinations
Ouch!
Hi everybody,
Here's some behavior I see on SBCL as well as LispWorks, so I'm
assuming for now they're right in doing so. My question would be why
they are.
I start with the following code which I compile and load:
(defvar *current-qualifiers* '(:a :b :c))
(defi
On Fri, Jul 3, 2015 at 11:02 AM, Alessio Stalla wrote:
> Package = map from symbol name to symbol object.
> INTERN ~= (or (gethash ...) (setf (gethash ...)))
> UNINTERN ~= remhash
I would consider that to be an implementation detail. As Anton said,
this is mostly about saving space and time. It
Perhaps the excerpt below (from a fresh LW image) makes more obvious
what my "philosophical problem" is. I have redacted the output of
DISASSEMBLE to only show the relevant parts. It shows that EQ is
essentially just one simple comparison with a machine word (which is
what I expected). It also s
On Fri, Jul 3, 2015 at 10:14 AM, Anton Vodonosov wrote:
> This doesn't break my PRINT-VALUE function, because the contract
> of my function is not to print lower case value when MODE is a symbols
> named "MYPKG:LOWCASE", but when MODE is exactly the symbol referred to
> in PRINT-VALUE.
I think th
On Fri, Jul 3, 2015 at 10:21 AM, Kenneth Tilton wrote:
> EQ, as you adroitly demonstrated, worries about all sorts of things,
> including a symbol's package.
Which is part of what has me confused. Up until now I would have said
that the "problem" of EQ is that it doesn't worry about _enough_
thi
e the same under EQL." (And maybe some more
sentences if necessary.)
On Fri, Jul 3, 2015 at 9:16 AM, Anton Vodonosov wrote:
> I think the most confusing part is what you mean by "same" symbols.
>
> 03.07.2015, 10:10, "Edi Weitz" :
>> Just out of curiosity an
Just out of curiosity and without any relevance in practise:
Is there one place in the standard where it is explicitly said that
two symbols which are the "same" symbol must be "identical"? I know
that there are a couple of examples where this is implied, but
formally the examples aren't part of
Not with SPLIT, but how about this?
CL-USER 1 > (ppcre:all-matches-as-strings "\\S+" " foo bar baz
frob ")
("foo" "bar" "baz" "frob")
On Thu, Jul 2, 2015 at 9:16 PM, Mark H. David wrote:
> The examples for cl-ppcre:split here
>
> http://weitz.de/cl-ppcre/#split
>
> include this tempting
Hi everybody,
After rummaging around in the HyperSpec and various implementation
manuals I came to the following conclusion:
1. The standard doesn't prescribe such thing as a default safety level
for CL implementations and there's no portable way to figure out the
safety level of the global envir
Happy New Year!
It works for me.
Cheers,
Edi.
On Tue, Jan 1, 2013 at 4:35 PM, Pascal Costanza wrote:
> Hi,
>
> Happy new year to you all!
>
> As the subject line says, common-lisp.net seems to be down. Does anyone here
> on the list happen to be able to fix this?
>
>
> Thanx!
>
> Pascal
>
> -
On Thu, Feb 3, 2011 at 8:35 PM, Charles Sullivan
wrote:
> Has a chameleon been suggested?
A lizard:
http://normal-null.de/lisp_logo.php
Edi.
___
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pro
On Tue, Jan 25, 2011 at 6:36 PM, Daniel Weinreb wrote:
> I actually can't remember why package prefixes
> aren't allowed. It was a long time ago.
They are allowed, aren't they?
http://www.lispworks.com/documentation/HyperSpec/Body/22_ced.htm
___
pro
On Thu, Jan 20, 2011 at 10:16 PM, Sam Steingold wrote:
> I think Franz, Lispworks, ITA et al are vital parts of the "lisp community".
> I think the fact that none of them is paying anyone to maintain SLIME,
> ALU wiki, common-lisp.net &c
> is indicative of understandable but deplorable corporate
There are lots of functions in the standard which are predicates in
that they return generalized booleans but on the other hand return
something "useful" if the result is not NIL, e.g. MEMBER or STRING<.
I think this is good practice, i.e. return something other than T in
case this might make more
On Fri, Dec 17, 2010 at 9:13 PM, Alexandre Rademaker
wrote:
> This is an old issue! We now have quicklisp!
How does Quicklisp solve the problem Gail described?
___
pro mailing list
pro@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/pr
On Fri, Dec 17, 2010 at 8:01 PM, Ala'a Mohammad wrote:
> I just want to point to another possibility, however, it's specific to
> CMUCL using the remote package
>
> http://common-lisp.net/project/cmucl/doc/cmu-user/ipc.html
Now that you mention it, LispWorks has something similar, albeit a bit
mo
20 matches
Mail list logo
