remove/key idiom works. Neverthless, differences still exists between the output of the interpreter and the text in the map.adoc file, which I am making the author of the original friendly aware of:- The command in the line 221 (remove/key m 'b) returns
whereas in the text, there is written:== #( a: 1 "c" 3 d: 99)== #( a: 1) - Examples in lines 240, 243, 246 produce outputs
b, a, Arespectively, whereas in the text, there is written'b, 'a, 'A.
As I'm translating email doc there is no mention about accessors:
>> system/catalog/accessors/email!
== [user host]maybe we can add
== Field accessing / accessors (not sure how to name it)
Username:
`` `red
>> e: user1@domain1.com
== user1@domain1.com
>> e/user
== "user1"
`` `
Host value:
`` `red
>> e: user1@domain1.com
== user1@domain1.com
>> e/host
== "domain1.com"
`` `before == Comparision?
In the float doc:
to binary! interprets the first 8 bytes as a floating point number.
I'm confused. Why should to binary! return float! (interprets as floating point number). Even if it means "using first 8 bytes" why not just something like this:
to binary! will use the first 8 bytes
That section could use some cleanup. Converting to and from should be clearer.
The any-list part could remove some prose.
An any-list! value must contain two numbers. The result will be the first number multiplied with the value of 10 to the power of the truncated second number.
first-number * (power 10 second-number)
Could be
An any-list! value must contain two numbers. The result will be
first-number * (10 ** second-number)
The binary example is backwards from the text. It described to float!. And your new text seems better. Beyond that, an example of what happens with truncated data (less than 8 bytes) should either be included, or we should say that's not supported.
* `to binary!` interprets the first 8 bytes as a floating point number. If there are fewer than 8 bytes, #{00} bytes are prepended.
```red
>> to binary! 42.3
== #{4045266666666666}char!? I know it's easy, but what is the use case?
Correct URL should be https://github.com/red/red/blob/master/environment/schemes/GPIO.red I'll inform the team.
And you can see the details by using expand-directives:
Red []
#macro pow2: func [n][to integer! n ** 2]
print pow2 10
print pow2 3 + pow2 4 = pow2 5
probe expand-directives [pow2 3 + pow2 4 = pow2 5]Output:
100
true
[9 + 16 = 25]Yes, that is a limitation, but may be change in the future.
2 other points:
You can also see the expanded version of your script by using --show-expanded argument during the compilation, for easier debugging:
Red []
#macro pow2: func [n][to integer! n ** 2]
print pow2 10Output:
Compiling D:\Projects\Red\red\build\bin\test.red ...
...using libRedRT built on 30-Jul-2019/13:43:21
[
print 100
]
...compilation time : 29 msAnd you may examine system/lexer/pre-load, default value is none but if you put a function there it will be called during the scanning (on REPL only, no effect on compiled exe)
>> system/lexer/pre-load: func [s] [replace s "*" "+"]
== func [s][replace s "*" "+"]
>> 3 * 5
== 8It can be used to extend to replace macros on REPL. There are better examples for use of pre-loader from @toomasv and others.
@endo64 I would argue against suggesting pre-load to newcomers (and pretty much everyone else), not until we get a decent reader macros support.
And you don't need compilation with -s, using expand from console is enough for quick experiments.
make action and native values. This is basically because the toolchain itself uses make to pre-define all actions and natives, and it was not deemed necessary or useful to forbid this feature after the initialization phase. However, (1) only existing actions and natives can be (re)made, and (2) the function spec has to be suppplied and if you get that wrong, a crash may occur. In "my" spec document, I have added wording to the effect that this is not recommened. Apparently, R3 alllowed it, but R2 did not.