World: r3wp

maybe with R4, after all of the goodies this opening will have brought, 
he will be able to contemplate opening up a bit more.  There is always 
a risk that letting go of *total* control can warp your creation 
to something you don't like.  But my experience in a decade of REBOL 
shows that stuff which isn't "sanctified" by RT have a lot of difficulty 
picking-up speed.


When you (i.e. Carl) spend 10 years on a project and it doesn't take 
off in-part because the responsability of keeping control stymies 
its growth, to a slower pace than that of the industry, IMHO you 
realize that the possible upside to *total* control definitely is 
dwarfed by having a mass of like-minded peers who move along with 
you.  


obviously no one sings exactly the same tune, but you need to try 
out stuff in order to know if its really a good or a bad idea... 
I'd rather have 100 people doing this, and then selecting the obvious 
clear winners than trying to muse about it, try a single idea and 
finally realize it wasn't a good idea.


Plus, what is good philosophy for RT isn't good for everyone... the 
proof is that the PITS model isn't enough for everyone.  Even RT 
had to acknoledge this.

REBOL "The language" is IMHO the best on the surface of Earth, but 
the platform (the actual executable, the desktop, view, IOS, et all) 
all show signs of tearing at the seams when you really want to "DO 
REAL WORK". 


You can get by, but its often painfull, or result to dubious work-arounds. 
  I have a lot of experience in big REBOL apps, so its not just word 
of mouth... I'm one of the few who has been succesffull at PITL work 
in R2 (hobby and commercial) for years.  But not everyone likes to 
say that problem-solving the platform itself is part of the work. 
 Most people want to work, they don't have time to try and fix view, 
or some tcp scheme, or charging their clients 30 hours to find a 
way to make 'CALL  work properly (or implement a MS COMLIB hack).

this looks like a vent, but its not.  I'm actually happy about everything 
that is happening with R3.   :-)

Every single broad decisision in R3 has been an enabling one for 
REBOL at large (both platform and language).   


Unfortunately, some things still require the core to be improved 
a bit, but we are nearing a point where REBOL will be able to fly 
on its own wings.   Just look at my attempt to get OpenGL to work 
with R3... it took me  10 hours of work from downloading the extension-enabled 
R3 version, downloading MS compiler, scrubbing the net for OpenGL 
reference material, libs, examples... and integrating all of this. 
 I've never coded OpenGL directly before... 


now imagine 100 of us doing this... that is what I see in REBOL's 
future within 2 years.  You will have things like trolltech QT bindings 
appearing, REBOL libs for any precise API out there... finally REBOL 
will be able to evolve with the rest of the world, and hopefully, 
impact its philosophy on the Computer Science more obviously...

JSON is a proof that it already has... now let's get that into the 
spotlight and start letting REBOL do what its really good at.... 
high-level application development...


 let it be the MCP for all the cool APIs, libs, network services, 
 game engines, web sites, smart appliances, etc... out there.


 (Refer to the movie Tron, for those who don't know what MCP stands 
 for... ;-)

What's JSON got to do with this?

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