Re: Equal branch
- Posted by jimcbrown (admin) Jun 25, 2014
- 1947 views
Hi
I have build the 'Egual' branch on Windows (32bit). Seems to compile out of the box. But what is the diff to the default branch? There is nothing in the created docs.
Maby the changes in the branch can be documented in the Doc's.
Andreas
It's a prototype branch to demonstrate feature changes. These changes may not necessarily ever be merged into the mainline - the branch is intended to demonstrate what can be done, but not necessarily what should be done.
In addition, even if a feature is later agreed upon and implemented, the prototype implementation may be found wanting (e.g. it may have serious performance problems), so even in that case changes originating from this branch may never make it into the mainline.
Basically, it's a place to stage demos.
Currently, it implements the following proposals:
append() and prepend() support using atoms as the first parameter.
sequence operations (e.g. and_bits({1,2},{2,1}) ) support sequences of differing lengths - the extra elements in the longer sequence are preserved unmodified in the result (aka the seqop nop standard). Previously, it truncated to the shorter of thw two sequences (aka the seqop truncating standard).
Sequences can be used as true/false values. An empty sequence is false, anything else is true (aka the false sequence standard).
Doing logical comparison in an if/while statement is the same as calling compare() or equal() (aka the DerekParnell standard). Previously, this was extended to all uses of logical comparison, even assignment to a variable (aka the no-seqop standard), however that is a backwards compatibility breaking change.
A new addition to the standard library is provided. Based on code by Pete Lomax, it implements the sequence operations purely through high level euphoria code. (This is probably not needed, it was intended as a replacement for backwards compatibilty reasons for any code that relied on the old seqop behavior if the no-seqop standard is adopted. An example of this is the 3.1.1 lower() and upper() routines.) Also, this library is entirely undocumented.
The reason these features in the branch are undocumented is because I'm too lazy to write docs for features that might not ever get put into the mainline. If they were mainlined, I'd still prefer to trust _tom's documentation skills over my own.
