search

metaeducation / rebol-issues

6 stars 1 forks source link

FORALL and FORSKIP of gob! #1595

Open rebolbot opened 14 years ago

rebolbot commented 14 years ago

Submitted by: BrianH

Gobs act like series in many ways, with series functions working on their pane, containing other gobs. They even have reference position (which came as quite a surprise to me). So in theory, it would be possible to have some of the loop functions be defined for gobs.

It would be helpful to have the loop functions FORALL and FORSKIP be defined for gobs. The reference position would be changed and restored afterwards in the same way as it is for series. Since FORALL and FORSKIP are the only traversing loops with no BIND/copy overhead on their code blocks, this could be useful for lowering overhead in GUI code. Based on feedback from the community, it appears that FORALL may be more important than FORSKIP for gobs, but there's no reason to not support both.

CC - Data [ Version: alpha 97 Type: Wish Platform: All Category: Graphics Reproduce: Always Fixed-in:none ]

rebolbot commented 14 years ago

Submitted by: Carl

So, are GOBs back to being series again?

rebolbot commented 14 years ago

Submitted by: BrianH

Yeah, sorry, I didn't know they had reference position before - I thought they only had absolute position, so they couldn't be series.

But I don't think gob! should be in the series! typeset because there are many operations that don't make sense for gobs: COPY, ALTER, SORT, RANDOM, set functions, and relative comparisons. I went through all the series functions evaluating applicability before coming to that conclusion. But the loop functions would work and lower overhead for traversal of sub-gobs, and the rest of the series operations are already supported.

Maxim wants COPY, but I don't see how it's feasible with all the reference cycles between faces and gobs. We can get by with MAKE.

rebolbot commented 14 years ago

Submitted by: BrianH

See #1605 for an explanation of why gobs are not series, even if they get support for the loop functions.

rebolbot commented 14 years ago

Submitted by: Carl

I agree they shouldn't be series. They're always going to be a bit "odd" in some important ways because they're designed to be optimized for graphics hierarchies.

Also, WRT allowing all the FOR* functions on GOBs... I considered that idea when adding GOBs, but seemed like usage would be quite rare (and writing the GUI prototype proved it) and adding GOBs will likely add additional conditional checks in the loop natives that will slow them down for what is a very rare case.

rebolbot commented 14 years ago

Submitted by: BrianH

This was requested by Steeve in AltME as an optimization for gob! use. However, the request was preemptive, in anticipation of potential use in porting the rich text editor from R2. There is no code yet that requires looping over gobs this way in a critical path.

Optimization is always about balance. Given a choice, making loops faster for series outweighs the overhead for gobs, especially since gob traversal can use the REPEAT x LENGTH? gob [gob/:x ...] method efficiently already. Steeve seems to agree; if you agree, Carl, then tickets #1595 through #1599 can be dismissed.

I also encouraged Steeve to help improve the built-in native rich text support of R3 once the graphics infrastructure is moved into the host code :)