World: r3wp

w> /refinement = 'refinement
== true

The question is, if the following would lead to a disaster?

w> integer! = 'integer!
== true

In any case, I wouldn't conflate that question with the question 
of #[true] = 'true.

There is a big difference between having datatypes be word values, 
versus having them fall under the any-word pseudotype. The latter 
seems OK, but not the former. If I understand you, it would cause 
things like [datatype? integer!] to fail, because it would return 
word!. That is, we lose them as an identifiable datatype. I use them 
for reflective tools and dialects. While the change wouldn't make 
that impossible, I like them being first class citizens as they are 
today.

No, let me clarify. I want integer! to represent a datatype, like 
1 represents an integer. So datatype? integer! should return true, 
and word? integer! should return false, just like decimal? 1 returns 
false.


I simple suggest equal? to return true, when comparing a datatype 
with a word of the same spelling. Like this is true:

>> equal? 1 1.0
== true

Technical speaking, it's an expanded coercion for the equal operator, 
=, (and so also for the equal? function).

What is the best way how to simulate R3's map! in R2? It would be 
enough to have safe key-value pairs?

in R3:
>> b: make map! ["a" "b" "b" "c"]
== make map! [
    "a" "b"
    "b" "c"
]

>> select b "b"
== "c"

in R2 I know only:
>> all [tmp: select/skip b "b" 2 first tmp]
== "c"

I really would like to know, why the hell is the result with /skip 
refinement in block:/

It's really sad to know, that we cannot expect any improvements in 
a future:/

MAP is an associative (Key <-> Value) data "storage". In R2 a correspoding 
way would be to use the hash! datatype, however, if you want to discern 
keys from values you need to use a separate Keys hash! and a separate 
Values block, otherwise you end up having Keys and Values intermixed. 
Your way of using the /skip refinement and a block is slower, however 
it searches only in Keys as well due to the /skip 2 use. When not 
used, it would search in Values.

(hope it explains it a bit)

I know the theory:/ To have separate hashes for key and values would 
be even more complicated. I would be fine if the select/skip would 
not return a block which is simply stupid... or correct me if there 
is any reason for that. It's sad we cannot have map! in R2.

In my case I will have just a few key-value pairs.. so the speed 
is not a problem, more important is to be safe that the key will 
not be mixed with values.

To have separate hashes for key and values would be even more complicated

 - that is wrong, there is no need to have two hashes, moreover, it 
 is not complicated, I wrote the corresponding software, and it is 
 easy

If I could move time back a few years and I could vote, I would like 
Carl to enhance R2 a little bit instead of starting R3 which he probably 
never finish.

Didn't he "say" that he was going to spend some weekend time on it?

Oldes, why don't you:

- ask for the R2 Map! code or
- write your own

instead of writing that "if I could"?

The question is when his weekend starts.. if his hour has so many 
minutes... but it would be nice to have his weekend using same hour 
type.

I have the code:

get-attribute: func[name /local tmp][all [tmp: select/skip attributes 
name 2 first tmp]]

but it's so UGLY.

And I will not ask.. I was asking so many times without any response 
that I gave up long time ago.

That is not complete in that it does not handle other operations 
than GET-ATTRIBUTE

I gave up even longer time ago offering my code :-p

...also, I am not sure, but maybe BrianH also offers his own version

Hm.. the reason for the additional block with the /skip is thi sone:
>> b: ["a" "b" "c" "d"   "b" "c" "d" "e"] select/skip b "b" 4
== ["c" "d" "e"]

Oldes: I was just about to write this, I asked is this a bug a few 
months ago, but no, it returns a block when you select with /skip 
because you can select more-than-one value if your skip size is > 
2 , otherwise you cannot get the further values. You select block 
of values when use /skip.

Maybe do somehing like:

>> keys: make hash! ["a" "b"]
== make hash! ["a" "b"]
>> values: ["b" "c"]
== ["b" "c"]
>> pick values index? find keys "a"
== "b"
>> pick values index? find keys "b"
== "c"

The
	pick values index? find keys
could be put in a nice function to call.

Or wrap it in a context:

map: context [
	keys: make hash! ["a" "b"]
	values: ["b" "c"]
	pick: func [value] [
		system/words/pick values index? find keys value
	]
]

>> map/pick "a"
== "b"
>> map/pick "b"
== "c"

of course... if you add one more condition to detect if the key exists... 
it does not change anything on the fact, that R2 is missing one of 
the basic functionalities natively.

Right.

I too wish, more work was put into R2, instead of doing R3. That's 
one reason, why I develop World.

That's the problem with closed source languages, if author doesn't 
add something, you're out of luck.

lol

Exactly! :)

Or ... if the language makes you do anything, like e.g. C, and what 
it does, it does well, then it doesn't matter, if it's closed source 
or not.

Geomol's right. R2 can be extended via DLLs, and R3 via extensions. 
But that might not solve all usage cases or needed fixes in Core 
...

I don't care, if my C compiler is closed source or not, because it 
just works. I also shouldn't care, if my COBOL compiler and interpreter 
is closed source or not, but I actually do, because the company behind 
can't figure out to make graphical tables (called GRIDs) the correct 
way, so my COBOL programs doesn't work as intended, and I have to 
create work-arounds. Years ago, I didn't care, if REBOL was closed 
source or open, but later I did, because I couldn't finish projects, 
I made with it.


Any future language, I would use, I don't care if it's closed or 
open, if it delivers, what it promices. If it doesn't, it's another 
case.

The problem is that what you think is the correct way to do things 
may be not

Others have needs you don't care in the end.

Ah, I have enough programming experience to figure out, if something 
is doable the 'right' way or not.

Lol, Are you 20 or what ?

:) nah

A good language is also easy to expand and integrate with other technologies. 
For some projects, it may be a good idea to have the language as 
a dynamic linked library.

We all do mistakes even after years and years of practices

We all do mistakes even after years and years of practices

sure

But that doesn't exclude, that if I use some time and think about 
some problem, I can figure out, if it's doable in some language the 
'right' way.

Geomol, I already know that you made some technical choices in World 
that I would not have done because I think (maybe I'm wrong) I know 
better ways to do faster VM.

So, to my mind,you already failed in the task to deliver a promising 
clone.

Just to say that your 'needs' , expectations and technical skills 
are probably not the best in each room.
;-)

I mean, even Carl failed in that matter. Everyone do shitty design 
choices occasionally. It's why it's better to have friendly eyes 
behind our shoulder.

That's the problem with closed source languages

 - there is nothing like "closed source language". Only an interpreter/compiler 
 may be closed source.

Lad +1


The REOL Syntax project is very important in this regard, and documenting 
the differences between the clones. Being the fastest VM my not be 
John's goal, if it means other tradeoffs.