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
}k: "div" once, and using :k in the path would be a big win. Or :div. :^)
json/("html")/("body")/("div")/4/("div")/("div")/("div")/2/("div")/1/("div")/("div")/1/("div")/:n/("div")/1/("div")/("span")
json/("html")/("body")/:div/4/:div/:div/:div/2/:div/1/:div/:div/1/:div/:n/:div/1/:div/("span")
json/("html")/("body")/:d/4/:d/:d/:d/2/:d/1/:d/:d/1/:d/:n/:d/1/:d/("span")
@greggirwin use parenthesis in path to select from an another block the position of the column I am searching for in the current one:
>> columns: [cd_ar 1 description 2 orders 5]
== [cd_ar 1 description 2 orders 5]
>> values: ["C00022" "Master Market" none none "22"]
== ["C00022" "Master Market" none none "22"]
>> values/(columns/description)
== "Master Market"
>>When column name sequence index name reflect data position I use the following form to pick the data form the right position.
>> columns: [cd_ar description something something-else orders]
== [cd_ar description something something-else orders]
>> values: ["C00022" "Master Market" none none "22"]
== ["C00022" "Master Market" none none "22"]
>> values/(index? find columns 'description)
== "Master Market"
>>