World: r3wp

We will publish this extension as soon as we have used it in a real 
life (internal) app to be sure it works.

Not using R3 for anything.

Reason: lack of energy. Illness took me down to about 1% of my programming 
capacity since about a year ago. Just starting to increase again 
recently.

robert, great to hear about the gui. what kind of styles you are 
planning?
some advanced ones like treeview etc.?

for now, whatever is needed for the application that is going to 
be built.

a textfield? ;-)

Do you know when is planed the unicode support in gui's textfields?

Or is it already there?

unicode will be fixed along with other DRAW bugs, when the host kit 
is done.

Peter, agreed, there are a bunch of related TRY and unwind bugs that 
need fixing. It's not blocking me as much as the PROTECT bugs, but 
it's there.

Anton, that explains a lot, sorry to hear about the illness. Glad 
you are recovering :)

Is it just me ... or is the official information about R3 undergoing 
further fragmentation?

We've got some prelim docs here on the host kit http://www.rebol.com/r3/docs/concepts/host-kit.html

but then we now see documentation in the change logs here  http://www.rebol.com/r3/changes.html
as well as here http://www.rebol.net/cgi-bin/r3blog.r?view=0324

http://www.rebol.com/docs/reference.html

missing 'funct  :)   Guess RebotTutorial got to Carl!

Fork mentioned FUNC vs. FUNCT naming issues.


As far as I am concerned, I am quite content with FUNC instead of 
LAMBDA as other languages using this construct "promote". Regarding 
the FUNCT name - as far as I remember, the FUNCTOR alternative was 
considered, but it looked impractically long for a common usage.

lambda/functor

 are better choices than "func/funct" because they aren't totally 
 made up.  But while they are not "warty" they are still "scary". 
  And most of Rebol is not that scary...with a few standouts (the 
 "re-" functions like rejoin and repend, and the /only refinement)

for you lambda is not "totally made up"? for me it is, it does not 
have any sense except in a narrow community

REPEND can be finessed in code which new users are going to be exposed 
to by just saying APPEND X REDUCE Y.  It would be nice if JOIN could 
do this as well.

fork, I undertand your gripe with /only.   but I'd rather have 'Only 
one refinement name to remember for all of the less processing fringes 
cases, than a different one for each of them... even in my code I 
use /only..... everytime I do other wise, I end up cursing, cause 
after a while I forget the refinement name and loose time looking 
it up.

join reduces the first argument, unfortunately.

I get bitten every few months, when I forget.

Ladislav: Well that's where the scary comes from, because although 
they are standardized somewhat within that community they carry along 
whatever impressions people have had about that small community, 
which isn't necessarily good.  The guy down the hall who writes everything 
in Haskell and can't cooperate with anyone... or whoever.

this does the exact same in less code

 X: rejoin [X Y]

My point is just about words appearing in early source that people 
are exposed to.  "rejoin" is one of those things that doesn't come 
off as intuitive as to what it means.

macro

 is a bit of a loaded term in languages (as some people would assume 
 "preprocessor macro" and not something more like "application scripting 
 macro").  But it looks friendlier and people would be less surprised 
 when set-words wrote into containing contexts.

The existing FUNCTION is a waste of the word and does nothing you 
can't do with /LOCAL so I really wish the mistake of using that word 
for it would be admitted and give it to FUNCT.

FUNCTION is one of the longest existing functions in REBOL. It is 
there since REBOL 1.x, when FUNC was not supposed to use /LOCAL. 
I still have some code working since then.

(as far as I remember, it was native back then)

Just to ease anybody's statements, that R3 will "require complete 
rewrites of existing code" - the change from R1 to R2 was much more 
"disruptive", as everybody can easily find out, and even then, a 
lot of code did not cease to work.

Rebol has a unique power to rework such things retroactively.  It 
would be possible to do a search/replace of FUNCTION in existing 
files with LOCALFUNC and then define it to behave appropriately in 
your R1/Forward, R2/Forward, etc.  My question is whether the unwillingness 
to bite such a bullet is worth the speed bump of explaining to every 
single user of Rebol in the future what a "FUNCT" is, forever... 
and ever... and ever...

No matter the names, you will have to explain all the FUNC versions 
anyway

People have to start using systems before they completely understand 
them.  The knowledge comes in bits.  Understanding of FUNCT (by whatever 
its name) is indeed necessary, but you often want people to be able 
to smile and nod as if they understand parts of a codebase that aren't 
immediately relevant to the point you're demonstrating.

The only function name I hate in R3 is FUNCT.   it doesn't read well, 
its not a proper abreviation, its not cute... its just look like 
a truncated word and is totally obscure in meaning.

And in lowercase it's too close to func while being very different...

I rarely agree with Fork  ;-)  on this one I TOTALLY agree.

Too close in uppercase too, actually.

Ah... so what's it like to finally feel some common sense?  :-)

Pretty soon this will become clear, too: http://hostilefork.com/2010/07/18/clocks-that-run-backwards/

I'd rather use something purposefully obscure like FCT.


if you're going to make a name shorter for the sheer reason of making 
it shorter... at least make it different.  


I would much prefer FUNCTOR.  its obscure, yes, but caries a sense 
of "find out what is the difference".  'FUNCT will go unnoticed for 
the majority of users.

I wouldn't mind if FUNCT was a shorthand for FUNCTOR.

Rebol doesn't make a habit in general of short names, and when it 
does I always wonder "why those".  Found some odd ones while working 
on Rebmu:

http://github.com/hostilefork/rebmu/blob/master/rebmu.r#L191

Carl says, he likes to use longer names, if the function is not meant 
to be used by end-users.

Fork, I won't say you're wrong on names, but you can't be right. 
:-) Naming is subjective, and there is no such thing as intuitive; 
unless you use natural language as the reference.

I like to feel like there's some matter of principle driving why 
the language doesn't define "app" for append or "rev" for reverse 
by default.  So yes, I'd use natural language as the reference in 
this case, but only because it seems like a convention which is *almost* 
followed but with these few exceptions that do not seem necessary.

REBOL is not about being as terse as possible. That's for Perl and 
Rebmu. I don't agree with all the designer's choices, but I can at 
least understand most of them. We all have things we don't like, 
and those things are different for each of us.

I feel like it's almost possible to teach people non-idiomatic Rebol 
and have it make sense from the get-go, where you can really focus 
on the code.  There are ways to keep from triggering "WTF" responses, 
like putting in parentheses when they're not strictly necessary. 
 And it seems so close that it's a shame the last little bit isn't 
done.

The catch is that "the last little bit" is not little at all. It's 
fundamental. I know you know that, but if we change REBOL to work 
like C and PHP people expect, that's what it will be.

experienced programmers have learnt to accept idioms like the requirement 
of parens on function calls.


they have to understand a different set of idioms.  "unlearning" 
that some of what they perceive as "fundamental" in programming is 
hard.


new programmers will have it the other way round if they learn REBOL 
first... why do we needs comas, and parens everywhere.... seems like 
waste.

where are refinements, things like that.

Depending on how you are presented with something, the "unlearning" 
can be either a joy or a suffering.  Put a kid on a bicycle with 
no training wheels and they fall and get hurt and they might not 
appreciate bicycles very much.  Give them some training wheels and 
let them get comfortable and be happy the day it comes off.

yes, but its still a bicycle. start them of on a tricycle and none 
of what they learned there it is usefull.  on a tricycle, if you 
lean you fall. on a bike, if you don't lean you fall.