World: r3wp

JSON was inspired in part by REBOL's simplicity.  tis almost a 1:1 
match to rebol's data model... just with a different syntax.

I'll only believe it when I can get this rebol-to-jason to work!

if more people could actually USE REBOL daily, we'd see more of the 
philosophy of REBOL trickling into the industry.   People forget 
that REBOL is born out of a different perspective on computer science.

I don't see why you're having so much trouble... when I read the 
JSON reference docs a few months ago, I could almost do a replace/all 
of a JSON data set to REBOL's  seems pretty obvious to write a lib 
for.f

could almost

lets do JSON discussion in javascript group....

They aren't in series! because they don't have position

What do you mean?

>> t: 11.22.33.44.55.66.77.88.99.00
== 11.22.33.44.55.66.77.88.99.0
>> t/5
== 55
>> third t
== 33

Some series stuff works with tuples, but not all like SKIP.

Ah, maybe you mean, my tuple t by itself doesn't have a position? 
So I can't do: next t

yep... the /1 /2  etc are accessors.

anyone know if any work is being done on the multi processing capabilities 
of R3 or if that has been definitely shelved for later?

later as in...  for 6+ months....

I think that Tasking will be postponed for 3.1, or 3.0 gets never 
released :-)

There were still talks in REBOL community about the model of concurency, 
and some other systems studied.

ok so won't even expect any kind of promise until this spring ... 
ah well

yes, it might be maing topic for May Prague DevCon, where 3.1 will 
be officially launched :-)

Maxim, the reason that custom datatypes can't extend the syntax is 
technical, not a control issue. When TRANSCODE/on-error was proposed, 
Carl revealed that TRANSCODE can't call out to external code on syntax 
exceptions without making it drastically slower, too slow for use. 
This is why the /error option was implemented instead: it doesn't 
use hooks or callbacks.


We do have custom datatype hooks for the serialized syntax constructors, 
but those are passed the preparsed REBOL data inside the #[ ]. Custom 
syntax hooks for ordinary literals would require a complete redesign 
of the parser, and that redesigned parser would be much worse, in 
terms of resource usage (speed, memory).

TRANSCODE/error *is* the junk! type, except it is (properly) an error! 
instead, just not thrown. You can process the info in that error 
and continue as you like.

TRANSCODE/error  good work around  :-)

It was the compromise Carl came up with - my idea was the /on-error 
option, but that was rejected because it required TRANSCODE to call 
back into a provided function, something Carl said was infeasible.

Ah, Carl's back from few days off. Started to fight spammers on blogs 
a bit :-)

John, re set-paren!, etc. dataypes - I am not a fan of those

re "symmetry between parens and blocks": "it make sense to me to 
have a lit-paren! datatype" no need, use:

quote (paren)

Is it a good idea, that blocks are not evaluated by default?

 - this is the way how dialects are supported; without it, you would 
 lose dialecting; EITHER, IF, LOOP, FUNC, etc. would have to be keywords, 
 not functions, ...

Ladislav, I seem to remember, you once argued against get-words (or 
was it lit-words) as arguments to functions? Like:
f: func [:som-set-word 'some-lit-word] [ ... ]

Did you write about that somewhere?

With QUOTE, Carl could also solve his block-path problem as:
(See http://www.rebol.net/r3blogs/0229.html)

>> user: [name: "Steve" age: 38]
>> user/(quote age:)
== 38

I prefer using a get-paren!:

user/:(age:)

On the other hand, I'm not a fan of letting user/age also search 
for set-words, lit-words and get-words.

Ladislav, I seem to remember, you once argued against get-words (or 
was it lit-words) as arguments to functions?

 - actually, that is a different matter. What I argued against was 
 "non-transparent" argument passing. The func [:argument] is not "just 
 a get-word", it is a specification of  "as-is argument passing". 
 As far as this one is concerned, it is much better than in R2; cf. 
 the QUOTE function, which cannot be implemented using any kind of 
 argument passing available in R2, while it is trivial in R3. The 
 "unevaluated words argument passing" specified by func ['some-word] 
 is still a different matter and I think that it is much less useful 
 than many users think. (e.g. the GET or SET function don't use it 
 for a good reason).

I wrote about it e.g. in http://www.fm.tul.cz/~ladislav/rebol/argpass.html
, but the article is a bit outdated

I only use lit-word parameters for console interactive functions 
(like CD) - otherwise it tends to be a bad idea. You can use get-word 
parameters for special tricks, but most of the standard special tricks 
have built-in functions in R3 implementing them already. It's usally 
easier to use one of the builtins (like QUOTE) than to navigate the 
tricks of reimplementing them.

There are a few years gone since I wrote my last c program under 
windows.
Just today I tried the extensions.
I was successful with Win-Lcc, but not with tcc.

Can someone tell me, if its possible to compile the extensions with 
tcc and how it should be done?

meassing lot of feature in tcc, are the extensions compilable with 
C compiler ?

or olny C++ ?

Only C for now - not C++. Some tweaks to the header will help with 
that. It's on my list to test with TCC :)

There are some platform-specific adjustments that the headers couuld 
be doing, but aren't yet. We could put TCC tweaks there.

2.100.80 released with new 'copy semantics ... let's test. Max - 
throw your 10K of your gfx nodes into it :-)

Thinking aloud for a bit in relation to the new Copy Semantics:
http://www.rebol.net/wiki/Copy_Semantics


What about the idea of protecting values. This way they won't be 
copied, when creatng a new object. Today we can protect words, but 
not values. So if a word is used for an indirect value, we can kinda 
change the word anyway (I say 'kinda', because we change the value, 
the word points to):

>> a: "a string"
>> b: a
>> protect 'a
>> change b "hmm"
>> a
== "hmmtring"


My idea is, that if we were able to protect values producing constants, 
this idea could be used to guide the creating of objects. And Copy 
Semantics could maybe be a lot simpler.

Submit your comment to the blog, please ...

Done.

Just for those ones who don't test.

To have the R2 behaviour of MAKE in R3, use COPY instead (without 
refinement).

Will images within objects be handled the same way in R2 and R3 then? 
;-)

i'ts not modified

R2 behaviour:

>> o: context [img: make image! 100x100]
>> o1: make o []
>> same? o/img o1/img
== false

R3 behaviour:

>> o: context [img: make image! 100x100
>> o1: copy o
>> same? o/img o1/img
== true

I don't think, your statement holds.

well

my mistake, but it's better that way, no ?

Would this seem like a REBOL way to create a constant?

define s "a string"

Used e.g. in an object this way:

o: context [
	define s "a string"
]


s can then be used as any other word, except it can't be modified 
(both the word and the value), and it won't  be cloned, when creating 
new objects from o.

Steeve, I can't judge that.

To me, the best way is, if the rules are so simple, you're never 
in doubt when programming. I compare these rules to operator rules. 
In REBOL, operators are evaluated left to right. It's a lot easier 
to remember, than having to look at page 53 in "The C Programming 
Language" every now and then, when I program in C, because I can't 
remember all those rules.


I guess, it would be dead simple, if all values were cloned by default, 
when creating new objects. And then use constants for those, that 
you don't wanna have cloned.

I have never used PROTECT. Do you guys use that? Maybe a warning 
system would be better!? hm

Geomol - with new semantics, you can choose datatypes, which values 
will be copied - copy/types [image!] for e.g., or something like 
that :-)