Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add vector-any, vector-every, string-any, string-every #883

Merged
merged 1 commit into from
Jan 29, 2024
Merged

Add vector-any, vector-every, string-any, string-every #883

merged 1 commit into from
Jan 29, 2024

Conversation

gambiteer
Copy link
Collaborator

I modeled the new code on the code for vector-for-each.

@gambiteer gambiteer merged commit 4602278 into gambit:master Jan 29, 2024
6 checks passed
@gambiteer gambiteer deleted the vector-cumulate branch January 29, 2024 01:05
@lassik
Copy link
Contributor

lassik commented Jan 29, 2024

As a user: thank you. This is the kind of unexciting but very important work that makes people start a given Scheme implementation by default.

@gambiteer
Copy link
Collaborator Author

Marc: I just studied what you did for any and every in lib/gambit/list/list.scm; you recently added lines like

            (or (macro-auto-force (apply pred args))
                (any-n* rests next-rests))

It's not clear to me why you added macro-auto-force, but should I add lines like this to vector-any and vector-every?

@feeley
Copy link
Member

feeley commented Jan 29, 2024

"auto-forcing" is enabled by a Gambit configuration option. It is intended to make (force arg) implicit on all strict operations. For example, (+ (delay 1) (delay 2)) is equivalent to (+ (force (delay 1)) (force (delay 2))). In the code you quote, the result of the pred procedure needs to be tested by the or, so the or operation is also a strict operation that needs to force the result of the pred procedure. Otherwise, if the pred procedure is (lambda (x) (delay (< x 0))) then the or would always think the result is non-false.

So yes this needs to be done for vector-any and vector-every?.

When Gambit implements (future <expr>) with promises and threads, it will allow the elegant expression of parallelism with (+ (future E1) E2).

@gambiteer
Copy link
Collaborator Author

gambiteer commented Jan 29, 2024

I'm looking at this now. In _std#.scm the arguments to proc in both vect-map and vect-for-each are not wrapped in macro-auto-force. Those should be wrapped, too, right?

Edit: The answer is no, sorry, I got confused.

Edit^2: That question didn't even make sense, but this is pretty subtle, you don't autoforce the last call to proc in tail position because it's returned.

@feeley
Copy link
Member

feeley commented Jan 29, 2024

The result of the procedure should not be auto-forced, neither for vector-for-each or vector-map, because the vector constructor is not strict. It is a different situation for u8vector-map because the u8vector constructor is strict.

@gambiteer
Copy link
Collaborator Author

(a) I guess I don't know what "strict" means.
(b) I can't find u8vector-map anywhere in the sources.

@feeley
Copy link
Member

feeley commented Jan 30, 2024

A function is "strict" on argument x if it needs to know the value of x to compute the result of the function. For example (sqrt x) is strict. A function is not strict on an argument x if it does not need the value of x to compute the result, or it only needs to know the identity of the value. For example (list x) is not strict. The point is that if x is represented as a placeholder for the result of some other parallel computation, then you can just put a reference to that placeholder in the list created by (list x), i.e. you don't need to wait for the other computation to be done before creating the list.

For u8vector-map I was just making an example. If it existed it would need to auto force the result of the function because there's no way to put a reference to a placeholder in a byte (but that's just implementation... it could be designed/implemented differently, for example if u8vectors had a full word of memory for every element of the u8vector).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants