World: r3wp

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.

Well, sure, the speed may not be the most important property.

Copying a cyclic block:

>> blk: [a b c]
== [a b c]
>> insert/only blk blk
== [a b c]
>> blk
== [[...] a b c]
>> copy blk
== [[[...] a b c] a b c]

That's not correct, right?

Ah, it is. I just realized, when I wrote it. :)

One question to library wrapping. I have a function, which should 
return a bool from C level, according to if the communication card 
is open, or not. When I am able to open the card, it returns 1 (mapped 
to R2 integer!), if not, it returns  30605312 - does that integer 
make any sence? I mean, does it e.g. translate to some C level slot, 
overflow, or -1 value? Just curious ...

w> to binary! 30605312 
== #{0000000001D30000}

Maybe you read too many bits?

I can't influence it, it is just result from the mapped function 
 C level code bool (dunno how it is defined) to R2's integer! value. 
Was just curious ....

Pekr, bool in C is usually of char type so you should try to set 
the returned value in your routine! spec to char.

Cyphre: thanks, will try that ...

Isn't it usually integer? It's must be defined somewhere btw.

In win.h include file in LCC compiler;
typedef int BOOL;
typedef unsigned char BOOLEAN;

BOOL != bool.

bool is in C since C99, and it's, in fact, *drumroll* a typedef/#define 
for _Bool

(before C99, there's simply no standard boolean type available in 
C)

Yep, WG14/N869 January 18, 1999 Page 257
#define bool _Bool

There are some other definitions in different include files:

typedef  enum _BoolValue {True=1, False=0, BoolValue_Max=2147483647L 
} BoolValue;
typedef int bool;  //lowercase
typedef unsigned char boolean;

typedef enum { false, true } bool;  // this is for Borland C I guess

BOOL != bool

 - this is strange, I never found any note mentioning other datatype 
 than int for bool. While Pekr may be experiencing bool to be defined 
 as something smaller, all the documentation I found mentions it should 
 be int.

The C standard is (as always) very vague and doesn't specify a particular 
storage size. I think it just defines that _Bool must be able to 
hold 0 and 1.

So when encountering a "bool", one really has to ask what kind of 
bool that is. More often than not, it won't be a C99 _Bool and will 
actually be int-sized.

If it is a C99 _Bool, it will typically be char-sized, though.

And I think Pekr really has a different case, because he's trying 
to use a C++ lib. C++ really has a bool, and I think it's char-sized 
(but I don't know whether that's impl-specific in C++ or defined 
in the C++ standard).

If it is a C99 _Bool, it will typically be char-sized, though.
 - hmm, I found explicitly stated that it should be int