World: r3wp

Re. new datatypes. Would all of set-paren!, get-paren! and lit-paren! 
make sense? Working like this:

>> a: 4
>> :(a)
== (4)		; type paren!
>> '(a)
== (a)		; type paren!
>> blk: [a b c]
>> (blk/2): 42
>> b
== 42

I suggested, a get-block! should work, so
:[a b c]
was the same as
reduce [a b c]
Maybe it's better, if it was:
reduce [:a :b :c]
?

I came to think of symmertry between parens and blocks. It make sense 
to me to have a lit-paren! datatype. What about a lit-block! datatype? 
The thing is, parens are evaluated by default, blocks are not. So 
a block acts like a lit-block! would, I guess. Is it a good idea, 
that blocks are not evaluated by default? A lot of functions take 
blocks as arguments. Some functions reduce their block argument, 
some don't. This can be confusing. If blocks were always evaluated, 
functions didn't have to reduce them. And then a lit-block! datatype 
would make sense.

Comments?

Example of functions, that treat they block argument differently:

>> first [a]
== a
>> print [a]
** Script Error: a has no value


If blocks were always evaluated, and we had lit-block!, it would 
look like this:

>> first [a]
** Script Error: a has no value
>> first '[a]
== a
>> print '[a]
a

Consequense is, functions had to be defined using lit-blocks... Nah, 
probably not a good idea. ;-)

*Consequence*

The tuple! datatypes is in the scalar! typeset. Isn't it more like 
a series? Maybe it's because, a tuple can be max 10 bytes!?

John; I've become quite a fan of REBOL unreduced block data.  Super 
handy and learning the wisdom of it is a right of passage.

tuple! is a scalar  imho, well a scalar "record"    insert 1.2.3.4.5 
6  would do what?

Maybe produce 6.1.2.3.4.5. Tuple has some series things to it:

>> second 12.34.56
== 34

Sorry John ... I had ^s turned off ... drop that last snarky bit 
about   insert.   Stupid question that could very well have some 
intelligent and reasonable responses.

:)

But I still see a tuple! as a scalar type with no head or tail really.

I hope, we can one day make new datatypes. I would make a complex 
datatype. Wouldn't it be cool to be able to calculate:

1.2+4.5i * 3.14+1i

Maybe it's too much to hope for, to be able to enhance the lexical 
analysis with new datatype recognision?

Or a range datatype:

>> blk: [a b c d e f g]
>> blk/3-5
== [c d e]

User-defined datatypes won't be recognized lexically, except perhaps 
in serialized form. However, serialized datatypes have to be REBOL 
syntax inside the block. It's too much to hope for REBOL to become 
Perl, or get Lisp's read macros.

You can use whatever syntax you like inside strings though.

Tuples are scalars because you can do math with them. They aren't 
in series! because they don't have position, same as bitset!.

John, actually previous version of rebol had "aggressive" evaluations 
on some blocks in some circumstances and it was quite annoying in 
fact.  it got removed in 2.3 IIRC forcing us to reduce a little more, 
but now we have control.

if the rebol parser catalogued junk, it could shift to custom datatype 
hooks (just like parse tries to match patterns) until it finds a 
rule that says... "YES... up to here, I know what this means".

it definitely is possible language-wise, we are already doing it 
with string parsing and using load/next.  The defining moment here 
is the decision by Carl to "let go" of  the total expressive control 
of the language, and that will not happen soon IIRC.  its already 
cool that he has decided to open source all but the deep core of 
the language.

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)