Accessor values question

Hey,
is there a function like values that would allow me to do this?

       (* (values 3 4)) ;; doesn't work, but is there something that does?

Thanks.

Sorry, but it's not really clear what you mean. If you want to use #'* with multiple values then use MULTIPLE-VALUE-CALL:

(multiple-value-call #'* (values 3 4))  => 12

If you want to replace VALUES by a different function then you could use APPLY and LIST:

(apply #'* (list 3 4))  => 12

Is this what you're looking for?

edgar-rft wrote:Sorry, but it's not really clear what you mean. If you want to use #'* with multiple values then use MULTIPLE-VALUE-CALL:

(multiple-value-call #'* (values 3 4))  => 12

If you want to replace VALUES by a different function then you could use APPLY and LIST:

(apply #'* (list 3 4))  => 12

Is this what you're looking for?

YES! Both methods are more than sufficient. One further question in regards to values, the objects returned by the function aren't really a list:

(funcall (funcall (lambda(f)(lambda(a)(apply f a)))#'*) (values 3 7)) ;; I initially used FUNCALL in the lambda body

;; returns : APPLY: argument list given to * is dotted (terminated by 3) ???!!

(funcall (funcall (lambda(f)(lambda(a)(apply f a)))#'*) '(3 7)) 

;; returns : 21

(which is why I was having trouble from the beginning), so what exactly is happening with the structure(?) of the values returned by values? Thanks for the assistance. Pax.

(funcall (funcall (lambda (f) (lambda (a) (apply f a))) #'*) (values 3 7))
=> APPLY: argument list given to * is dotted (terminated by 3)

The error message is misleading. IMO this is is a bug in your Common Lisp implementation. A correct error message should read "The value 3 is not of type LIST" or similar.

The reason is that Common Lisp functions do not handle multiple values by default:

(funcall (lambda (a) ...) (values 3 7))

Here the parameter variable a is bound to the the primary value (the integer 3), and all following values (the integer 7) are ignored.

Multiple values are explained here:

• Practical Common Lisp, Chapter 20, Section Multiple Values
• Common Lisp, the Language, 2nd Edition [CLtL2], Section 7.10.1 Constructs for Handling Multiple Values

CLtL2 is older than the ANSI Common Lisp specification, so in case of doubt look-up the MULTIPLE-VALUE-... operators in CLHS, but the explanation in CLtL2 is much better than CLHS Section 5.1.2.3 VALUES Forms as Places.

edgar-rft wrote: The reason is that Common Lisp functions do not handle multiple values by default.
Multiple values are explained here:

• Practical Common Lisp, Chapter 20, Section Multiple Values
• Common Lisp, the Language, 2nd Edition [CLtL2], Section 7.10.1 Constructs for Handling Multiple Values

CLtL2 is older than the ANSI Common Lisp specification, so in case of doubt look-up the MULTIPLE-VALUE-... operators in CLHS, but the explanation in CLtL2 is much better than CLHS Section 5.1.2.3 VALUES Forms as Places.

Thanks, I've read the section in PCL, it was really good, and will read the others you listed in a bit.

edgar-rft wrote: The error message is misleading. IMO this is is a bug in your Common Lisp implementation. A correct error message should read "The value 3 is not of type LIST" or similar.

Frankly, I have to agree with your opinion. I've run into many situations where the errors returned have given little or incomplete information. I'm also frustrated by its lack of built-in thread support. If you know of a good implementation that plays well with Emacs/Slime and does threads right out the box, let me know. Again, thanks for your help.

SBCL has good support of threads nowadays.

Hey, Goheeca!
I've been using Cygwin on Windows 7, (don't laugh), for development which doesn't have a port for SBCL. So I went to their site, downloaded the x86 installer, ran it, started SBCL, evaluated *features* and there was absolutely no thread package! So a quick search turned up:

SBCL wrote: Threads are part of the default build on x86[-64] Linux only.

They are also experimentally supported on: x86[-64] Darwin (Mac OS X), x86[-64] FreeBSD, x86 SunOS (Solaris), and PPC Linux. On these platforms threads must be explicitly enabled at build-time, see INSTALL for directions.

It will be a few months before I have FreeBSD up and running again, so I almost gave up until I found this, which is a fork of a fork of SBCL by Anton Kovalenko. I installed, ran it, and of course tested it:

(make-thread (lambda()(write-line "Hello, world")))

;;; caught STYLE-WARNING:
;   undefined function: MAKE-THREAD
;
; compilation unit finished
;   Undefined function:
;     MAKE-THREAD

pretty verbose. So then I remembered and tried:

* (sb-thread::make-thread (lambda()(write-line "Hello")))

Hello
#<SB-THREAD:THREAD RUNNING {23E1BB49}>

so I'm not really sure what is going on, but I'm happy so far. I'll probably setup some sort of environment to play around with SBCL. Thanks for this!

BTW, how the heck do I kill the thread?? o.0

macrolyte wrote:... how the heck do I kill the thread?

See the SBCL User Manual, Section 12 Threading.

Clozure CL is also known for running on Windows, see Clozure CL on Windows and Programming with Threads.

A pretty complete overview about the capabilites of the various Common Lisp implementations can be found here:

• Daniel Weinreb: Common Lisp Implementations: A Survey

The document if four years old but 99% still true, except such things like "the SBCL Windows support today is much better than it was in 2010"...

I'm using Cygwin, too . Kovalenko's fork has been merged quite recently. I was using Kovalenko's fork before merging. Despite saying that SBCL is running on Windows experimentally, the unmuffleable initial message Your Kitten of Death awaits has disappeared so it's getting better. In *features* of original SBCL is available :sb-thread. You should install bordeaux-threads to have functions like make-thread at disposal.