Non-Expanding BLOCK! Idiom?

Usage Questions
1

(Extracted from Portable Bridge Notation thread.)

Is there a prescribed way of declaring a block! (or similar structure) to be non-expanding, allowing it to contain only the # of elements of its defined size? If you insert into the block, the last value is automatically purged. (Maybe if you append to the block, the first element gets taken.) Optionally could declare the block with default values.

Background: Sometimes I want to keep a "cartridge" of values meeting the spec of a certain length, and it may be as simple as a LIFO/FIFO list where I want to hold onto "the most recent" X things, and then just be able to immediately FORM/MOLD etc. into an output.

This is easy to achieve with a normal block, but it grows and grows and then you have to truncate it each time (not a big deal) and process it for your intended output.

Just a code-golf thought. Maybe there's a structure that already handles this though... I haven't dug into this.

1 Like
Portable Bridge Notation (PBN) Parser
2

Rebol tries to get away with "everything is a BLOCK!". But having data structure interfaces that add more functionality to blocks... or remove functionality from blocks (if the operation would compromise the data structure rules)... is important.

BLOCK! is a bit of a too-simple foundation for "interesting" data structures. But although we now can have an arbitrary number of Extension Types, it doesn't seem like making people use a C compiler just to make something like a STACK! or QUEUE! (or the structure you describe here).

I've become more amenable to things like @rgchris's Node Proposal, where we'd offer a type that could serve as a foundation for more kinds of data structures.

But your non-expanding block could probably be done without Node, but just be a class of some type that wrapped blocks. We need to make it possible to make classes that hook into things like APPEND and such, and that's getting closer...

1 Like