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

Remove wasted transparents, COLLECT beautify #137

Merged
merged 1 commit into from
Nov 1, 2015
Merged

Remove wasted transparents, COLLECT beautify #137

merged 1 commit into from
Nov 1, 2015

Conversation

hostilefork
Copy link
Member

The original implementation of <transparent> was fairly trivial, and it
often marked cases of functions that would do code where the code
passed in was foreign. So they weren't where the buck stopped with
a return, rather it would continue to the caller.

That usage of transparent is no longer interesting or necessary...a
passed in RETURN living inside of CODE knows its binding and where
to go. But there are cases where is actually needed, for
instance where instead of DO-ing foreign code you are using that code
as the body of a function as part of your implementation.

Two good case studies of this are USE and COLLECT. And COLLECT
is such a good case study of the Zen of language extension using Rebol
that now that it's working, I wanted to clean it all the way up. But there is
an issue in keeping <r3-legacy> mode working if it's changed, due to
a nuance interfering with the trick that usually lets "I want TRUE
refinements" vs. "I want WORD-valued refinements" live in peace. :-/

But rather than just accept that I went ahead and made the code itself
conditional so that the real example could be read, not intermingled with
the ugly stuff. Even with the APPLY and no definitional returns, "getting"
the original was one of my main inspirations for the pursuit of fixing the
missing system pieces to get it to its near-final (if not final) form...

The original implementation of <transparent> was fairly trivial, and it
often marked cases of functions that would **do code** where the code
passed in was foreign.  So they weren't where the buck stopped with
a return, rather it would continue to the caller.

That usage of transparent is no longer interesting or necessary...a
passed in RETURN living inside of CODE knows its binding and where
to go.  But there are cases where <transparent> is actually needed, for
instance where instead of DO-ing foreign code you are using that code
as the body of a function as part of your implementation.

Two good case studies of this are USE and COLLECT.  And COLLECT
is such a good case study of the Zen of language extension using Rebol
that now that it's working, I wanted to clean it all the way up.  But there is
an issue in keeping <r3-legacy> mode working if it's changed, due to
a nuance interfering with the trick that usually lets "I want TRUE
refinements" vs. "I want WORD-valued refinements" live in peace.  :-/

But rather than just accept that I went ahead and made the code itself
conditional so that the real example could be read, not intermingled with
the ugly stuff.  Even with the APPLY and no definitional returns, "getting"
the original was one of my main inspirations for the pursuit of fixing the
missing system pieces to get it to its near-final (if not final) form...
@hostilefork hostilefork merged commit 37efbbe into metaeducation:master Nov 1, 2015
@hostilefork hostilefork deleted the victory-dance branch November 2, 2015 10:17
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.

1 participant