triplet!+pair! idea. Mainly because usually you expect a point of a certain dimensionality. View expects 2D pairs, while some theoretical 3D engine parts will expect 3D triplets. So it makes sense to enforce that dimensionality by the typing rather than bother with extra length checks. If there will appear a case where both 2D and 3D points should be accepted, one can always make a typeset: point!: make typeset! [pair! triplet!].
Moreover, most modern CPUs do floating-point arithmetic as fast as (or even faster than) integer arithmetic
After skimming thru https://www.agner.org/optimize/instruction_tables.pdf I have to agree. It's on par speedwise, and float multiplication can even be twice faster than that on integers.
pair! as a literal value, instead of encountering it as an intermediate computation result? With images we reason in terms of x and y amount of pixels (discrete values, integers), and rarely think of subpixel position - rather, it's almost always a result of some precise geometric computation, hidden behind graphical facade.
pair/x and pair/y as number. We use it a flag sometimes. For example, In a text editor, we may use pair/x to store the line number, usepair/y as bitset flag to store some information. In this case, we cannot use float32. But it is kind of hacking code, I think we should just 2 integers. Or use vector! if we need to record every lines in the text editor.
cell! size to fit such extra info. Though, we can return that info on syntax errors, that case is trivial.
- Every 2D point could be considered also a 3D point, also conversion between float and int could be seamless:
>> 1x1 == 1.0x1.0x0.0 - My wish - could we make possible using parens like in
path!?>> 1x(pow 3 2) == 1.0x9.0x0.0 - In special cases (discrete image pixels, editor line hacking) we can always use
vector!ofinteger!s.
as-coord helper to start, and see if paren notation still has enough value.
@greggirwin @giesse this proposed paren notation for me is natural consequence of having similar mechanism in defining path!s, which is very convenient for me:
>> a: [b [c 123]]
== [b [c 123]]
>> get to path! reduce ['a (to-word "b") 'c]
== 123
>> a/(to-word "b")/c
== 123So, for me 1x(pow 3 2) is more easy to read/understand and shorter than as-coord 1 pow 3 2. At first glance you see that this expression is a coord!.
@loziniak I'm used to parens in paths from many years of Reboling, though I don't use them often. However, they are still considered an experimental feature in Red, as we are not sure they are worth keeping.
To make sure I understand your example, you have code with 2 known values and variable key between them, like accessing a keyed record's field. Here's a more efficient way to do that, which seems clearer to me:
>> a: [b [c 123]]
== [b [c 123]]
>> k: to word! "b"
== b
>> a/:k/c
== 123Does the path approach give you some other benefit that I don't see at a glance?
x), which is not "special" like /, it opens up a lot more questions and potential ambiguity. Paths are specifically meant for indirect access, and have to start with a word. Do pairs in your design have to start with a literal number, or is (pow 3 2)x(pow 2 3) valid as well? Because that's no longer Red compatible as a syntactic form. If that's not valid in your design, you can only evaluate the y axis, which seems much less useful and general.
x part of pair! defined by paren!. That kindda invalidates my idea.
:point_up: September 27, 2019 11:16 AM @9214, you're going to Hell for that. ;^) Lacking the power to send you there, I will have to concede that it's an AWFULly cool idea for a dialect.
@loziniak forgive me for not trying to come up with a more meaningful name in a short chat example. ;^)
get-field-c-from-var-a-for-rec: func [
key [string!]
][
key: to word! key
a/:key/c
]
a: [b [c 123]]
get-field-c-from-var-a-for-rec "b"rec-id.
word! instead of index in the cases where that is applicable, but then it would need to know if that word! was being reused in that branch of the tree...
For the reference, the main argument against paren! in paths is a stylistic one: you can abuse them with multi-line expressions or ungodly mess like inclusion of external files and deeply nested code logic.
head/(
...
<you can embed whole Red runtime here for all I care>
...
)/(
...
)/tailOne path (no pun intended) we can take is to prohibit newlines during path! lexing, thus allowing only simple, single-line expressions. Another is to get rid of them entirely.
page: 1 per_page: 10
for page 1 41 1 [
out: probe join out-head [per_page * page - per_page + 1 "-" per_page * page ".json.txt" ]
file: read to-rebol-file out
probe length? file
file: head remove/part file 3 ; remove initilal (UTF?) garbage
json: json-to-block file
;probe copy/part mold json 100
for n 2 11 1 [
attempt[insert/only tail items json/("html")/("body")/("div")/4/("div")/("div")/("div")/2/("div")/1/("div")/("div")/1/("div")/:n/("div")/1/("div")/("span")]
]
page: page + 1
if (probe length? file) < 90 [break]; 75
]
probe count: length? items
{
probe items/2/1/("a")/1/("#text") ; creator
probe items/2/1/("a")/2/("@href") ; link
probe items/2/1/("a")/2/("strong")/("#text") ; filename
probe items/2/2/("#text") ; description
}