World: r3wp

Today I posted more philosophical topic, and Carl noticed it - we 
ares shooting ourselves in the foot. Here's what I posted:
-------------------

There will always be problem with dialects, if they contain the same 
keyword names as REBOL functions. So we have to somehow live with 
that.


So the question is, where to introduce new name and why, just to 
be different, and where to not. E.g. parse 'copy keyword has already 
different semantics to REBOL's one, or VID's 'at has different semantics 
to REBOL's one. Now can users be confused? It depends.


I try to think about each dialect in the context of the dialect itself 
- so the only measure for me actually is, when reading the source 
code (or trying to understand one's), how quickly I am able to understand, 
what is going on?


But then we could as well replace 'stay by 'save-position, 'of by 
'any-of, 'if by 'only-if, etc., which would imediatelly map the meaning 
to what the keywords are really doing. But we are somehow mysteriosly 
looking for one-word-only-mantra naming convention, and I suppose 
it is already our style, and we will not change it :-)


... so, the topic is a little bit more abstract - it is about contexts, 
and user/programmer switching between contexts, and his/her ease 
of understanding of the code.


In above case, all 'if, 'check, 'either are OK, even if their semantics 
is a bit different to their REBOL counterparts.

I do agree

your rant towards EITHER not fitting anything breaks the initial 
purpse dialecting was brought to REBOL! And the meaning is - the 
same word, might mean different things in various contexts. We don't 
care for VID to use potentially the same keywords to REBOL functions, 
let we do care somehow mysteriously about PARSE to NOT use the same 
keyword naming as REBOL functions. Let's judge EITHER by its name, 
not by its REBOL level meaning.

Yeah, the name EITHER, exactly the reason I've had a problem that 
proposal since it was proposed in December.

The name EITHER was why I put "maybe" on the proposal.

If the english meaning of EITHER does not describe well what is intended, 
then let's not use it, otherwise let's use it. I noticed Carl created 
scenario, which allows to be really flexible. If no word can fit 
its meaning properly, then let's use the symbol. If we can find word 
for it, which will help users to imediatelly see, what the code does, 
let's use the name with no prejudices ...

It doesn't.

not with carl's last  example and syntax, but using blocks it would... 
without any lost in capabilities.

I might agree with Max here -sometimes I prefer already existing 
syntax being reused, instead of coming-up with additional semantic 
jumbo-mumbo :-)

It definitely is not an easy decision. I would proceed as following 
- take Carl's examples, and try to express/describe them in human 
words - simply how you would write a manual for them. The look at 
what you wrote once again, and if you find there is plenty of "either" 
words, then use it :-)

my point is just that blocks will be used so often anyways, because 
of recursive rules, that I see no point in using "|"  as I say, in 
every complex parse I've done,  I have to separate the "|" by blocks 
anyways... they just don't roll-back very well in practice.

ah, you are a purist, you would remove even | ? :-)

Not in R3, they work fine. And any bugs will be fixed.

pekr, not in the general rule, cause otherwise we'd need some new 
word to say "OR" these blocks.

The only problem I have with | is where to put it in multi-line rules 
- end of line, or new line? :-)

but brian... ALL real parse rules are so complext that we need to 
properly define the groups of "|" between them... so the point is 
moot even if they do work better now.

we still need to put rules in blocks, just about all the time.

and now with carl's example this will be even more so.

Max - we want to sensibly extend/fix parse, not to break what we 
are already used to, no?:-)

5:16 here ... should continue my sleep, I woke up at 3:00, or I will 
look drunk at work :-) ....

hehe, don't get me wrong, I like that R3 PARSE is finally being addressed... 
I think carl waited sooo long because he knew there would be a storm 
about it  ;-)

i started the port of areatc to rebol 3 ... so far i hate the way 
to stilize gobs all those words to put every where yeeeeeeeeeeeeerk 
... my gob does already more than 10  lines and do nothing on screen 
!!!

stylize [

area-tc : [

	about: "Area displaying in color keywords in text"
	
	facets: [
		size: 400x400
		max-size: 2000x2000
	]
	options: [
		size: [pairs!]
	]
	
	faced: [ 
	]
; internal face funcition:

	
; events handler
	actors: [
	
	
	]
	
]


]

i ned some help what is the equivalent of init in R3/VID ? and is 
there a draw: embeded to a gob how can i say my custom face inherits 
from box style ?

found how inheriting box style

hum apparently text instruction in draw doesn't apply colors !

The R3 equivalent of VID isn't done yet, and some revisions are planned.

hm ? i'm using VID the demo one and i'm not in a good mood !!! What 
the fuck is that shit is that the improvements i heard about during 
month and month ? 


So to be simple and keep my cool i will not port area-tc or viva-rebol 
to R3 until it's finished

The improvements have been to lower-level parts of R3. The work on 
the GUI made it abundantly clear that the lower levels needed some 
work. We've been doing that work. Part of that is the parse imoprovements 
that we're working on right now, which will help with improving the 
VID dialects.

load-gui 



; area-tc stylized gob -custom widget-

areatc-obj: context [


	stylize [
	
		 area-tc: box [
		
			about: "Area displaying in color keywords in text"
			
			facets: [
				size: 400x400
				max-size: 2000x2000
			]
			options: [
				size: [pair!]
			]
			faced: [ 
			]
		; internal face funcition:
		
		; empty draw block ...
			draw: [ fill-pen red text 20x20 [  "test" ] ]
			
		; events handler
			actors: [
		
			]	
		 ] ; fin area-tc style
	] ; end stylize
]; end areatc-obj
view [
    area-tc
]


 to draw in the end a black text over a background default colored 
 with a shape and color i didn't choosed that's not not not cool at 
 all  too much code for a useless thing and a wrong result.

Carl has some new ideas that will help fix the resize model, and 
we will be working on those when work on the GUI resumes.

yeah around 2012  and meanwhile I wait ... pfff ok since carl is 
actually working on parse to make it more friendly to idiots like 
me I will say i will wait.

Hew, I've been waiting for the parse enhancements for 5 years, or 
more recently since November. You won't have to wait that long.

Hew -> Hey

I'm frustrated max ... i saw carl working on parse i wanted to take 
that opportinuty to start adapting area-tc to r3  and VID just is 
unfinished not even exploitable to do a starting of a begining of 
a test work ....  i though text instruction as been reformed last 
time carl working on GUI  and that we could use thing like text pos 
[ color1 "string1" color2 "string2" color3 '"string3" etc ...]

but in fact that's the same old draw we had in R2 ...

The Unicode enhancements haven't made it to the GUI yet. We haven't 
been working on the GUI since spring.

hum apparently the sting arguments in text draw is able to "rejoin" 
strings given in a block and you can't give strings to text instruction 
without embeding them to a black

It took a while to even propagate the Unicode and moduule changes 
across the core, let alone the GUI.

yeah ... i believed what people told me you can almost use Vid to 
do area-tc  thing is it's not the case at all ...

Oh, which people? Never mind, it doesn't matter.

button "Close" [quit] that doesn't work neither ?

what i have to do then button "Close" with [actor: [ on-lick: [quit]] 
] ?

ho it's button "close" do [quit]

button "close" quit

ok an just to unview the window  how can i do ?

unview self works ?

I don't recall. Henrik?

we where not talking about VID... just the gob... and did tell you 
that unicode was not yet part of the GUI  :-)

Yead, VID is supposed to make gobs easier to use. Working with gobs 
directly will be verbose and tricky.

yeah but what is the relation betwin the unicode and the fact that 
text instruction draws a text in black when i request it to be red 
?