From: Tamas
Subject: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <8328dfb6-6298-421c-a067-ebcc5f776308@j78g2000hsd.googlegroups.com>
Hi,

I have the following problem: suppose there is a function I am calling
for its side effects, yet it returns a value, which is huge (think of
an array with 1e6 elements, etc).  Lisp handles the value perfectly,
but if this occurs in the REPL, the result will be printed, which
slows Emacs down.

What would be the standard way of preventing that?  Currently I am
using something like

(defmacro invisible (&body body)
  `(progn
     ,@body
     (values)))

(invisible
  (calculation-with-large-results ...))

but I wonder if there is a standard way.

Another, related question: is there a generic method for displaying a
conscise representation of an object?  Something like describe, but if
the object is really huge, it would display only part of it (eg first
10 elements of a vector, etc).

Thanks,

Tamas

From: Brian
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <a65fb556-7f32-4f0c-8913-3ed9d7ce80a4@i72g2000hsd.googlegroups.com>
I use the something very similar to your invisible macro to suppress
returning a value.

I know that some implementations when printing a big list will print
it something like (1 2 (3 4 #) # 6 7).  I think the same may apply to
vectors also.
From: Rainer Joswig
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <joswig-39C1C0.23093716012008@news-europe.giganews.com>
In article 
<····································@j78g2000hsd.googlegroups.com>,
 Tamas <······@gmail.com> wrote:

> Hi,
> 
> I have the following problem: suppose there is a function I am calling
> for its side effects, yet it returns a value, which is huge (think of
> an array with 1e6 elements, etc).  Lisp handles the value perfectly,
> but if this occurs in the REPL, the result will be printed, which
> slows Emacs down.
> 
> What would be the standard way of preventing that?  Currently I am
> using something like
> 
> (defmacro invisible (&body body)
>   `(progn
>      ,@body
>      (values)))
> 
> (invisible
>   (calculation-with-large-results ...))
> 
> but I wonder if there is a standard way.

Returning no values is fine.

> Another, related question: is there a generic method for displaying a
> conscise representation of an object?  Something like describe, but if
> the object is really huge, it would display only part of it (eg first
> 10 elements of a vector, etc).
> 
> Thanks,
> 
> Tamas


See *print-length* , *print-level*, *print-array and others.
Some Lisps have own variables to control printing.
From: Tamas
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <d5b239b6-ee62-45ad-bdad-174f6378e50a@e6g2000prf.googlegroups.com>
On Jan 16, 5:09 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@j78g2000hsd.googlegroups.com>,
>
>
>
>  Tamas <······@gmail.com> wrote:
> > Hi,
>
> > I have the following problem: suppose there is a function I am calling
> > for its side effects, yet it returns a value, which is huge (think of
> > an array with 1e6 elements, etc).  Lisp handles the value perfectly,
> > but if this occurs in the REPL, the result will be printed, which
> > slows Emacs down.
>
> > What would be the standard way of preventing that?  Currently I am
> > using something like
>
> > (defmacro invisible (&body body)
> >   `(progn
> >      ,@body
> >      (values)))
>
> > (invisible
> >   (calculation-with-large-results ...))
>
> > but I wonder if there is a standard way.
>
> Returning no values is fine.
>
> > Another, related question: is there a generic method for displaying a
> > conscise representation of an object?  Something like describe, but if
> > the object is really huge, it would display only part of it (eg first
> > 10 elements of a vector, etc).
>
> > Thanks,
>
> > Tamas
>
> See *print-length* , *print-level*, *print-array and others.
> Some Lisps have own variables to control printing.

Thanks.  I am writing a print-object method for my sparsematrix
class.  When printing arrays with *print-array* set to nil, I get a
hex number that I guess uniquely identifies the array:

CL-USER> (defparameter *a* (make-array 20 :initial-element 2))
*A*
CL-USER> *a*
#(2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2)
CL-USER> (setf *print-array* nil)
NIL
CL-USER> *a*
#<(SIMPLE-VECTOR 20) {B65CB5F}>
CL-USER>

How can I get something similar for an arbitrary object (an instance
of my class?)  I am using SBCL, but it would be good to have something
portable.

Thanks,

Tamas
From: Kent M Pitman
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <uwsq8xcpy.fsf@nhplace.com>
Tamas <······@gmail.com> writes:

> CL-USER> *a*
> #<(SIMPLE-VECTOR 20) {B65CB5F}>
> CL-USER>
> 
> How can I get something similar for an arbitrary object (an instance
> of my class?)  I am using SBCL, but it would be good to have something
> portable.

CL-USER 1 > (defclass my-class () ())
#<STANDARD-CLASS MY-CLASS 2068CA2C>

CL-USER 2 > (defmethod print-object ((x my-class) stream)
              (print-unreadable-object (x stream :type t :identity t)
                (write-string "my summary here" stream)))
#<STANDARD-METHOD PRINT-OBJECT NIL (MY-CLASS T) 2069BA2C>

CL-USER 3 > (make-instance 'my-class)
#<MY-CLASS my summary here 206A6C6C>

Typically you might make the write-string print the name of the object,
not a constant string.  Though you could bind *print-length* and other
values and print the array contents again, or even do your own custom
abbreviation in a more ad hoc way.
From: Barry Margolin
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <barmar-4570F4.00312517012008@comcast.dca.giganews.com>
In article 
<····································@j78g2000hsd.googlegroups.com>,
 Tamas <······@gmail.com> wrote:

> Hi,
> 
> I have the following problem: suppose there is a function I am calling
> for its side effects, yet it returns a value, which is huge (think of
> an array with 1e6 elements, etc).  Lisp handles the value perfectly,
> but if this occurs in the REPL, the result will be printed, which
> slows Emacs down.
> 
> What would be the standard way of preventing that?  Currently I am
> using something like
> 
> (defmacro invisible (&body body)
>   `(progn
>      ,@body
>      (values)))
> 
> (invisible
>   (calculation-with-large-results ...))
> 
> but I wonder if there is a standard way.

I usually just type (progn (whatever) nil).  This is only one more 
character than (invisible (whatever)).

BTW, it doesn't need to be a macro:

(defun invisible (&rest vals)
  (declare (ignore vals))
  (values))

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Kent M Pitman
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <usl0wxcbq.fsf@nhplace.com>
Barry Margolin <······@alum.mit.edu> writes:

> In article 
> <····································@j78g2000hsd.googlegroups.com>,
>  Tamas <······@gmail.com> wrote:
> 
> > Hi,
> > 
> > I have the following problem: suppose there is a function I am calling
> > for its side effects, yet it returns a value, which is huge (think of
> > an array with 1e6 elements, etc).  Lisp handles the value perfectly,
> > but if this occurs in the REPL, the result will be printed, which
> > slows Emacs down.
> > 
> > What would be the standard way of preventing that?  Currently I am
> > using something like
> > 
> > (defmacro invisible (&body body)
> >   `(progn
> >      ,@body
> >      (values)))
> > 
> > (invisible
> >   (calculation-with-large-results ...))
> > 
> > but I wonder if there is a standard way.
> 
> I usually just type (progn (whatever) nil).  This is only one more 
> character than (invisible (whatever)).
> 
> BTW, it doesn't need to be a macro:
> 
> (defun invisible (&rest vals)
>   (declare (ignore vals))
>   (values))

Or, alternatively, just return (values), since (invisible) doesn't convey
the correct information about what's going on.  A better name for invisible
would be without-values.

In MACLISP, for what it's worth, I used to sometimes return the symbol
whose name was backspace, because it didn't print visibly but was
re-readable in files.  I also sometimes made a datatype that printed
without showing anything.  In CL, that's easy to do.  [Don't forget to
handle *print-readably*, though, either by erring or by not printing 
invisibly.]

CL-USER 23 > (defstruct pointless)
POINTLESS

CL-USER 24 > (defmethod print-object ((p pointless) stream)
 (when *print-readably* (call-next-method)))
#<STANDARD-METHOD PRINT-OBJECT NIL (POINTLESS T) 2069920C>

CL-USER 27 > (make-pointless)

CL-USER 28 > (let ((*print-readably* t)) (print *))

#S(POINTLESS) 

CL-USER 29 > (read-from-string "#S(POINTLESS)")
13

CL-USER 30 > (let ((*print-readably* t)) (print *))

#S(POINTLESS) 
From: szergling
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <d38678f7-429d-4ca7-9a0b-584b403667c6@e6g2000prf.googlegroups.com>
On Jan 17, 10:43 am, Tamas <······@gmail.com> wrote:
> Hi,
>
> I have the following problem: suppose there is a function I am calling
> for its side effects, yet it returns a value, which is huge (think of
> an array with 1e6 elements, etc).  Lisp handles the value perfectly,
> but if this occurs in the REPL, the result will be printed, which
> slows Emacs down.
>
> What would be the standard way of preventing that?  Currently I am

Besides all the suggestions previously mentioned in this thread, I
also use (null (expr)), which is quite quick to type in the REPL.
From: Rob Warnock
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <3YqdnQfFIc9Fvg3anZ2dnUVZ_sWdnZ2d@speakeasy.net>
szergling  <···············@gmail.com> wrote:
+---------------
| Besides all the suggestions previously mentioned in this thread, I
| also use (null (expr)), which is quite quick to type in the REPL.
+---------------

NOT is even shorter!   ;-}   ;-}


-Rob

-----
Rob Warnock			<····@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: szergling
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <e701d0e0-9f9b-4627-be51-adebb4932292@c23g2000hsa.googlegroups.com>
On Jan 18, 4:58 pm, ····@rpw3.org (Rob Warnock) wrote:
> szergling  <···············@gmail.com> wrote:
>
> +---------------
> | Besides all the suggestions previously mentioned in this thread, I
> | also use (null (expr)), which is quite quick to type in the REPL.
> +---------------
>
> NOT is even shorter!   ;-}   ;-}
>
> -Rob

Damnit, I've been scooped! That seems like the optimal solution -- the
global minimum! I've searched through all symbols (including some
non-CLHS ones), and there's no other shorter ones.

(let ((x (list)))
  (do-symbols (s)
    (let ((name (symbol-name s)))
      (when (<= (length name) 3)
        (push s x))))
  (sort x #'< :key (lambda (sym)
                     (length
                      (symbol-name sym)))))

(* > T < / = - * + S P X GC PI ++ 1+ ** >= // OR DO EQ /= IF <= GO ED
 1- IT FN PS VAR ARG INT MAP MOD LCM *** LDB GET MIN SIN SET DO* ///
 +++ ELT EXP AND DPB COS POP ASH NTH NIL CDR NOT LOG THE CAR REM MAX
 GCD ABS BIT EQL LET TAN CIS ZIP AIF DIR SYS SRC SYM)

Well, (= (expr)) almost made it, but it only works for expressions
returning numbers. Could be useful for suppressing bignums...

I'll be back to one up c.l.l one day. Just you wait.
From: szergling
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <02e4574d-d601-4829-ad17-d5906993f22e@d21g2000prf.googlegroups.com>
On Jan 20, 8:54 am, Kent M Pitman <······@nhplace.com> wrote:
> szergling <···············@gmail.com> writes:
> > On Jan 18, 4:58 pm, ····@rpw3.org (Rob Warnock) wrote:
> > > szergling  <···············@gmail.com> wrote:
>
> > > +---------------
> > > | Besides all the suggestions previously mentioned in this thread, I
> > > | also use (null (expr)), which is quite quick to type in the REPL.
> > > +---------------
>
> > > NOT is even shorter!   ;-}   ;-}
>
> > > -Rob
>
> > Damnit, I've been scooped! That seems like the optimal solution -- the
> > global minimum!
>
> Uh, you could use DEFUN to make a shorter name in your init file for
> interactive use, of course.

Yes :) it all depends on whether or not you count (fixed vs variable
costs) the defun form itself. ;)
From: Chris Russell
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <5d0ac027-edb4-4605-bde4-41801bfe2c3a@p69g2000hsa.googlegroups.com>
On 20 Jan, 04:25, ····@rpw3.org (Rob Warnock) wrote:
> Chris Russell  <·····················@gmail.com> wrote:
> +---------------| szergling <···············@gmail.com> wrote:
>
> | > I've searched through all symbols (including some
> | > non-CLHS ones), and there's no other shorter ones.
> |
> | T beats it.
> | as in:
> |   >(verbose-fn)t
> |   T
> | at a single keypress you're going to be hard pressed to beat it.
> +---------------
>
> Hunh?!? Which CL gave the above result?!? I suspect you didn't
> actually try this, or you would have discovered that it's incorrect
> [or at the very least quite non-portable]. All of several CLs I tried
> gave the following expected result instead:
>
>     > (loop for i below 100 collect i)t
>
>     (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
>      25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
>      47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68
>      69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90
>      91 92 93 94 95 96 97 98 99)
>     >
>
>     T
>     >
>
> [Well, one of them unexpectedly ate the "T" (perhaps because its
> REPL uses GNU "readline"), but *none* of them ate the long result.]
>
> -Rob
Then it's a slime based inconsistency, that doesn't depend on the
compiler being used.
Since I never use the command line to work at the repl, I thought it
was standard behaviour.
From: ···············@gmail.com
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <2fbeb96b-d40d-42f7-9468-2d290bfce432@i12g2000prf.googlegroups.com>
On Jan 16, 4:43 pm, Tamas <······@gmail.com> wrote:
> Hi,
>
> I have the following problem: suppose there is a function I am calling
> for its side effects, yet it returns a value, which is huge (think of
> an array with 1e6 elements, etc).  Lisp handles the value perfectly,
> but if this occurs in the REPL, the result will be printed, which
> slows Emacs down.
>
> What would be the standard way of preventing that?  Currently I am
> using something like
>
> (defmacro invisible (&body body)
>   `(progn
>      ,@body
>      (values)))
>
> (invisible
>   (calculation-with-large-results ...))
>
> but I wonder if there is a standard way.
>
> Another, related question: is there a generic method for displaying a
> conscise representation of an object?  Something like describe, but if
> the object is really huge, it would display only part of it (eg first
> 10 elements of a vector, etc).
>
> Thanks,
>
> Tamas

If you want to inspect the result later, a quick shortcut is something
like

(defparameter *result* (function-returning-big-object))

DEFPARAMETER returns the symbol naming the variable.
From: Kaz Kylheku
Subject: Re: what's the standard way to make results in the REPL "invisible"
Date: 
Message-ID: <9a1354d9-507d-4614-ad91-e729863bf41b@c23g2000hsa.googlegroups.com>
On Jan 16, 1:43 pm, Tamas <······@gmail.com> wrote:
> Hi,
>
> I have the following problem: suppose there is a function I am calling
> for its side effects, yet it returns a value, which is huge (think of
> an array with 1e6 elements, etc).  Lisp handles the value perfectly,
> but if this occurs in the REPL, the result will be printed, which
> slows Emacs down.
>
> What would be the standard way of preventing that?  Currently I am
> using something like
>
> (defmacro invisible (&body body)
>   `(progn
>      ,@body
>      (values)))
>
> (invisible
>   (calculation-with-large-results ...))

Why does it have to be reduced to no value whatsoever? A single NIL
value is almost equally unobtrusive. Then you have more options.

> but I wonder if there is a standard way.

Let's see. First, the lame ways:

  (if (calculation ...) nil) -> NIL

  (and (calculation ...) nil) -> NIL

  (progn (calculation ...) nil) -> NIL

The creative-lame:

  (prog1 nil (calculation ...)) -> NIL

The semantically cleanest, but not least verbose: the program with
empty variable set:

  (prog () (calculation ...)) -> NIL

Now for the better ones, starting with the obscure. With no clauses,
the controlling expression of a CASE simply evaluated, and the result
is NIL.

  (case (calculation ...)) -> NIL

Unlike IF, whose consequent expression is not optional, all of the
consequent forms in WHEN are optional, so that a one-argument WHEN is
permitted. This gives us:

  (when (calculation ...)) -> NIL

All of these require you to live with a NIL result instead of no
result.

And now for what might be considered winning entry, demonstrating a
good balance of terseness and clean semantics of intent:

 (tagbody (calculation ...)) -> NIL

From CLHS: ``The statements in a tagbody are evaluated in order from
left to right, and their values are discarded. If at any time there
are no remaining statements, tagbody returns nil.''.  There you go. :)