comp.lang.scheme Google Group

Re: Wraith Scheme 1.36 released (shareware parallel R5 Scheme for Macintosh)

2009-11-27T17:14:45Z

On Tue, 17 Nov 2009 01:10:40 -0800 (PST), Jay Reynolds Freeman
This link is rerouted to the Web site at the following URL when
clicked:
Home
[link]
This link is incorrect, and actually leads to the same above-mentioned
Web site when clicked. The correct link follows:

Re: Any Chez Scheme/Petite Chez Scheme-specific mailing list/newsgroups?

2009-11-27T15:37:28Z

I'm sure most of us would appreciate some good topics here. If they are
about Chez, I know I would. ;-)
Aaron W. Hsu

Re: mutually recursive streams

2009-11-27T15:06:31Z

Just a little update: I can also place the (delay (force )) inside the
definition of fps-int. This way the definitions of fps-sin and fps-cos
become very elegant again...

Re: mutually recursive streams

2009-11-27T14:55:15Z

I did have a look at the CL code. I am still trying to understand how it
works.
That would be an option. However, when I use define-stream-constructor
for the definition of stream-int, the definitions of sine and cosine
become more elegant:
(define fps-sin
(fps-int fps-cos))
(define fps-cos
(fps-subtract fps-one (fps-int fps-sin)))

Re: mutually recursive streams

2009-11-27T13:10:42Z

By the way, did you look at the CL code? It uses odd streams, but avoids
the problem you bumped into by wrapping the sine and cosine definitions
in a delay (which is not completely unlike even streams). In short, you
can use your initial code, but change the final part to:
(define stream-cos-promise

Re: mutually recursive streams

2009-11-27T11:43:10Z

For the interested:
I added a Scheme section to
[link]. The solution still
uses odd streams. Maybe sometime I will try to implement a solution
using even streams.
Daniel

Re: Any Chez Scheme/Petite Chez Scheme-specific mailing list/newsgroups?

2009-11-27T02:59:22Z

On Thu, 26 Nov 2009 20:15:15 -0600, Aaron W. Hsu <arcfide@local>
wrote:
It seems that the issue probably boils down to one of a combination of
both quality and quantity of posts. People shouldn't need to go to
the plt-scheme mailing list to enjoy the same combination of quality
and quantity of posts about a Scheme implementation as exists there.

Re: Any Chez Scheme/Petite Chez Scheme-specific mailing list/newsgroups?

2009-11-27T02:19:18Z

Indeed, there is a lot of quality issues, but I wonder how much of that
is simply because people don't care to put quality in. I think sometimes
that people see a noisy group and don't realize that they can filter out
much of the noise.So they try to go elsewhere, until that becomes too
popular and the noise shows up again.

Re: Any Chez Scheme/Petite Chez Scheme-specific mailing list/newsgroups?

2009-11-27T02:15:15Z

What makes you think that adding a new group will make a difference? If
there isn't any traffic, it is because people aren't posting. Post a
question about Chez, and see if something happens.
I don't see the problem here.
If you think that you're going to get more traffic with a more specific
group, I don't think you'll find it. There isn't a ready made cohesive

[nausicaa's library of the week] Nausicaa/CURL 2009-11-26 tag 0.1a0

2009-11-26T22:03:17Z

Nausicaa/cURL
=============
Nausicaa/cURL is a distribution of Scheme libraries for R6RS
Scheme implementations; it provides bindings for the cURL C
language library. It is built upon the Nausicaa/Scheme
package, making use of its foreign-functions interface.
cURL is a tool to transfer data to or from a server, using

Re: Any Chez Scheme/Petite Chez Scheme-specific mailing list/newsgroups?

2009-11-26T16:41:06Z

On Thu, 26 Nov 2009 17:06:40 +0900
Im my experience the PLT mailing lsit has by far the most traffic of
all Scheme-related discussion ressources. So it is not really "even".
Or he could just use comp.lang.scheme?
So splitting off a comp.lang.scheme.chez-scheme group, would lead to
more discussion than there is comp.lang.scheme? Must be some kind of

Re: mutually recursive streams

2009-11-26T14:14:43Z

Thanks a lot for your reply. I guess I didn't try it like this, because
apply works on lists. I oversaw the fact that streams are also lists.
Very nice! It works perfectly like this. I still need to read up on
define-syntax.
So it seems that even streams are somehow more elegant than the odd
ones. I will try to work out how this problem can be solved with odd

Re: mutually recursive streams

2009-11-26T13:03:12Z

Is this what you're looking for?
(define (stream-add . streams)
(apply stream-map + streams))
Both stream-map and stream-int are functions, not macros, so stream-sin
needs to be evaluated prior to function call; thus the error. What you
need is to delay the evaluation of stream-sin variable till it's defined.

Re: Different evaluation of nested define and "global" define

2009-11-26T10:33:40Z

The second define is like (set! money (- mody 10))
Now set! and define are quite different.
(define var value)
The value is evaluated in an environment including tjhe new binding of
var.
(set! var value)
The value is computed. If it refers to the var, the old value is used.
Here first a new binding is made for money. The old binding is

mutually recursive streams

2009-11-26T10:11:42Z

Hi group,
I recently started learning Scheme. At the moment I am playing with
streams / lazy lists. More specifically, I am trying to solve the
problem described at [link].
The idea is to use lazy lists for the Taylor series expansion of
functions. These should then be used to define the sine and cosine