[DOC] Undocumented features
copy
is the only (or the first among many) actions that accepts pair!
argument for its /part
refinement; pair!
in such case denotes a "slice" to copy over:
-
x
coordinate denotes an offset relative to series' index, inclusively; -
y
coordinate denotes an offset relative to series' index, exclusively.
This feature appears to be either buggy or inconsistent. See design discussion.
Examples
>> block: at [a b c x d e f] 4
== [x d e f]
>> copy/part block -3x0
== [a b c]
>> copy/part block -100x0 ; why?
== [a b c x d e f]
>> copy/part block 5x-1 ; always the case if Y <= X
== []
>> copy/part block 0x3 ; 0 is treated as -1
== [c x d]
>> copy/part block -1x3 ; ???
== [c x d e]
Objects permit tracking cumulative changes to their fields via changed
reflector, which returns a block of words, denoting modified fields.
Examples
>> foo: object [x: 1 y: 2]
== make object! [
x: 1
y: 2
]
>> set foo [bar baz]
== [bar baz]
>> reflect foo 'changed
== []
>> do bind [x: y: 0] foo
== 0
>> reflect foo 'changed
== [x y]
modify
can be used to clear the accumulated changes by passing none
(the only accepted type of argument in this case):
>> modify foo 'changed none
== make object! [
x: 0
y: 0
]
>> reflect foo 'changed
== []
>> set 'foo/x 1
== 1
>> reflect foo 'changed
== [x]
>> put foo 'y 2
== 2
>> reflect foo 'changed
== [x y]
pick
can be used to check if a given char!
value (or a block/string of them, or a UCP numeral, or even a charset spec) belongs to character set denoted by bitset!
value.
Example
>> upper: charset [#"A" - #"Z"]
== make bitset! #{00000000000000007FFFFFE0}
>> pick upper to float! #"O"
== true
>> pick upper to integer! #"z"
== false
>> pick upper uppercase "abracadabra"
== true
>> pick upper "abracadabra"
== false
>> pick upper [#"X" #"O"]
== true
>> pick upper [#"x" #"O"]
== false
>> pick charset [#"A" - #"C"] [#"C" - #"E"] ; intersection
== true
>> pick charset [#"A" - #"C"] [#"D" - #"E"] ; no common elements
== false
Same holds for path notation:
>> upper/(#"Y")
== true
>> upper/(#"i")
== false
An excerpt from here.
Icons and other "resources" are now supported for inclusion in Windows executables (TBD: check the other platforms). They can be set from Red’s main script header, these are the currently supported options:
Icon: file! or block! of files
Title: string!
Author: string!
Version: tuple!
Rights: string!
Company: string!
Notes: string!
Comments: string!
Trademarks: string!
If no Icon option is specified, a default Red icon will be provided.
#include-binary
preprocessor directive accepts file!
or string!
argument that denotes a file path to binary data to be inlined as binary!
value. Useful for embedding application’s resources, at the cost of beefing up the size of the resulting executable.
A lexical form for string!
values that treats its content literally, without a need for escape sequences.
Example
>> {kawaii ^^_^^}
== "kawaii ^^_^^"
>> %{kawaii ^_^}%
== "kawaii ^^_^^"
The number of %
symbols on both sides should be equal, to address the unlikely event where the string itself contains }%
-like patterns:
>> %%{raw strings end with }% followed by 0 or more %}%%
== "raw strings end with }% followed by 0 or more %"
Both Red and Red/System are published under the BSD license. The runtime is published under the BSL license.