The What is a PORT! post says something that is often said in things written by (presumably) Carl:
"In Rebol 2, ports were built on a pure series model. However, we found this approach to be problematic because ports are not pure series. They also embody state (information)."
"Rebol 3 moves away from the pure series model of Rebol 2 and more toward an I/O stream model. Now it is closer to the concept found in other programming environments and languages."
The pure series model is gone. Ports are more pragmatic now, and this has resulted in a port system that is cleaner, smaller, faster, and more extensible than ever before.
But that doesn't seem to be people's experience. I haven't heard this newfound "smaller/faster/more-extensible" pleasing anyone in particular. Mostly just people complain that they didn't have the ports they used to have.
My questions:
What about Rebol2 port code made it a "pure series"? You couldn't PARSE a PORT! in Rebol2, I don't think. How was it "pure" or "impure"?
Is there any case of something that didn't work in Rebol2 that was suddenly able to work in R3-Alpha? e.g. an example of Rebol2 code where the R3-Alpha is better?
Does anyone have an example of going backwards? Where Rebol2 code was good and R3-Alpha seems wrong?
There was much more documentation about the r3 ports than for rebol 2. I wouldn't have attempted a r2 port due to this. But I was able to do all the protocols that were present in r2 with just a little help.
Also, r3 was asynchronous so that allowed the GUI to work unblocked. Whereas in r2 any network activity blocked the GUI.
But due to asynch nature some things are more complex.
I do find the Rebol 3 port interface to be much cleaner. Rebol 2 ports made a lot of assumptions in their design about a scheme being specifically a stream of bytes from somewhere and contained a lot of hidden state mechanics that had to be managed:
This didn't really make much sense where a scheme did not behave in this way. Pretty much any secondary scheme (that is, one built on top of a lower-level scheme—TCP, FILE, e.g. HTTP, MYSQL, S3) is likely more abstract.
I had the idea once that I could make an in-memory port that would return a calculated series just-in-time - like some languages have iterators. Perhaps it would be some incremental dialect thing. But ports are assumed to be tied to external/network activity - so that was too heavyweight for the ideas.
Why not just use an object for that? I was just playing. A scheme offered a single "class" to put the definition while opening "multiple instances". It was an object that not only can primarily receive block messages but also reacts to control events like being opened and closed.
Finalisation...
I wrote a Rebol2 scheme called DO-POP for manipulating mailboxes via POP. According to the documentation I said I used a port because a port will receive a close event when Rebol shuts down. I don't think such a finalisation event was available anywhere else in Rebol2. This event provided me the opportunity to issue a graceful quit to the server even if the client script/user quit without closing the port. It's always been an annoyance to me that a finalisation event isn't available generally in Rebol.
Writing a scheme for R3-alpha was just as difficult as writing for Rebol2 because in both cases I don't think the concepts had been refined and documented properly - too much reverse engineering and sherlock holmesing… Pushing data through is one thing, then there's the control aspect.
The other possible advantage for r3 was that downloads can be sent to disk, but all r2 reads were in memory which caused memory issues for large files. However, Anton Rolls did do a large file downloader for r2.