values->list elements

values->list elements

[Jon Wilson]

Hi y'all,
Is there any sensible way to implement the following semantics:

(+ (values 1 2))
==>
3

Or perhaps with a macro of some sort (but preferably as above)...

(+ (values->list-elements (values 1 2)))
==>
3

The intermediate step (after the macro expansion I guess) would look like

(+ 1 2)
==>
3

It seems like this would make multiple values much much more useful.

Regards,
Jon


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[szgyg]

Jon Wilson wrote:
> Is there any sensible way to implement the following semantics:
> 
> (+ (values 1 2))
> ==>
> 3
 >
> Or perhaps with a macro of some sort (but preferably as above)...
> 
> (+ (values->list-elements (values 1 2)))
> ==>
> 3

! untested code !

(define-macro (values->list vs)
    `(call-with-values (lambda () ,vs) list))

(apply + (values->list (values 1 2 3)))

or

(define-macro (make-cockeyed-function f)
    `(lambda (vs) (apply ,f (values->list vs))))

((make-cockeyed-function +) (values 1 2 3))

> The intermediate step (after the macro expansion I guess) would look like
> 
> (+ 1 2)

No, this is impossible without redefining +. A macro produces 1 sexp, 
not more.

> It seems like this would make multiple values much much more useful.

szgyg

ps: GNU Free Software Directory list guile-1.6.7 as recent


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Jonathan Wilson]

Hi szgyg,

szgyg wrote:
> No, this is impossible without redefining +. A macro produces 1 sexp, 
> not more.
> 

This is exactly what I am getting at.  values does return more than 1
sexp, but the mechanisms for using that are clumsy and painful.  It
seems that if values returns multiple s-expressions, then they should be
treated as multiple s-expressions.  In between a set of parentheses, N
s-expressions are usually treated as N elements of a list.  Why should
values be any different?

(list 0 (values 1 2) 3)
==>
(0 #<values(1 2)> 3)

This is strange.  If we had

(list 0 (values 1 2) 3)
==>
(0 1 2 3)

Then multiple values would actually be useful.

Regards,
Jon



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Neil Jerram]

szgyg <szgyg@freemail.hu> writes:

> (define-macro (values->list vs)
>     `(call-with-values (lambda () ,vs) list))
>
> (apply + (values->list (values 1 2 3)))

Yes, but why does this need to be a macro?

(define (values->list vs)
  (call-with-values (lambda () vs) list))

> or
>
> (define-macro (make-cockeyed-function f)
>     `(lambda (vs) (apply ,f (values->list vs))))

Same here, I think.

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Neil Jerram]

Jon Wilson <j85wilson@fastmail.fm> writes:

> The intermediate step (after the macro expansion I guess) would look like
>
> (+ 1 2)
> ==>
> 3
>
> It seems like this would make multiple values much much more useful.

I've often thought that too.  IMO multiple values per R5RS are a
pretty half-baked concept.

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Jonathan Wilson]

Ah... great minds DO think alike!
Regards,
Jon

Neil Jerram wrote:
> Jon Wilson <j85wilson@fastmail.fm> writes:
> 
>> The intermediate step (after the macro expansion I guess) would look like
>>
>> (+ 1 2)
>> ==>
>> 3
>>
>> It seems like this would make multiple values much much more useful.
> 
> I've often thought that too.  IMO multiple values per R5RS are a
> pretty half-baked concept.
> 
> Regards,
>      Neil
> 


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Per Bothner]

If you make "multiple values" first-class then you get into an
interesting and useful design space.  See the XQuery language
(http://www.w3.org/XML/Query and http://www.w3.org/TR/xquery/).
Its values are "sequences" of "items".  The difference between a
list and a sequence is that sequences don't nest directly - and
there is no difference between an item and a sequence of length 1.
You can handle nesting by wrapping a sequence in a node or object
(though the latter goes beyond the XQuery data model).

XQuery doesn't goes as far as it could, because a parameter
list is not a sequence, but a list of sequences.  It would be
cleaner to define a parameter list as a sequence, and then
use pattern matching to split the sequence into parameters.

Sequences are nice because they're the natural result of
"statements" such are loops (see XQuery's FLOWR expressions)
or "blocks" (bodies in Scheme).

In Kawa XQuery sequence and Scheme multiple values are
implemented the same way.

Articles where I explore / ramble on this idea:
http://www.gnu.org/software/kawa/q2/
http://per.bothner.com/papers/LispXML04/index.html
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[szgyg]

Jonathan Wilson wrote:
> szgyg wrote:
>> No, this is impossible without redefining +. A macro produces 1 sexp, 
>> not more.
> 
> This is exactly what I am getting at.

Oh, yes, I see.

This isn't a new idea, but the original semantic.

| (this is not a serious proposal for a language extension,
| but only an example):
| (1) Wherever n consecutive arguments might be written in
|     a function call, one may instead write {f x1 ... xm}n,
|     where n is a positive integer. The "function" f must
|     return n values, which are used as n arguments
|     in the function call.
| (2) The primitive (values x1 ... xn) returns its n arguments
|     as its n values. Thus writing "{values x1 ... xn}n" is
|     the same as writing "x1 ... xn" as arguments in a
|     function call.

[Guy L. Steele: LAMBDA: The Ultimate Declarative, 1976, p 18-19]


I think however, that explicit function transformer is a reasonable alternative.

szgyg


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Neil Jerram]

szgyg <szgyg@freemail.hu> writes:

> This isn't a new idea, but the original semantic.
>
> | (this is not a serious proposal for a language extension,
> | but only an example):
> | (1) Wherever n consecutive arguments might be written in
> |     a function call, one may instead write {f x1 ... xm}n,
> |     where n is a positive integer. The "function" f must
> |     return n values, which are used as n arguments
> |     in the function call.
> | (2) The primitive (values x1 ... xn) returns its n arguments
> |     as its n values. Thus writing "{values x1 ... xn}n" is
> |     the same as writing "x1 ... xn" as arguments in a
> |     function call.
>
> [Guy L. Steele: LAMBDA: The Ultimate Declarative, 1976, p 18-19]

Interesting!  So how come RnRS turned out not to include this?

Regards,
     Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[szgyg]

Neil Jerram wrote:
> szgyg <szgyg@freemail.hu> writes:
> 
>> This isn't a new idea, but the original semantic.
> 
> Interesting!  So how come RnRS turned out not to include this?

I don't know exactly, but see

Steele & Gabriel: The Evolution of Lisp, 1993, page 57-59.

szgyg


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Jon Wilson]

Hi,
> 
> Steele & Gabriel: The Evolution of Lisp, 1993, page 57-59.

This can be found here:

http://www.dreamsongs.com/NewFiles/HOPL2-Uncut.pdf

In this pdf, I think the relevant section is pages 85-87.

I'm not sure what HOPL stands for, though.
Regards,
Jon


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: values->list elements

[Per Bothner]

Jon Wilson wrote:

> This can be found here:
> http://www.dreamsongs.com/NewFiles/HOPL2-Uncut.pdf
  > I'm not sure what HOPL stands for, though.

History of Programming Languages, IIRC.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user