AltME groups: search

& would be infix, a replacement for STAY (originally called AND, 
then AT).

its like saying 


when I say implied, I really mean that you cannot just look at rules 
like they are now with a single use bblocks for many rules.  it terminates 
 somewhere later ... you must find an  | statement....  which doesn't 
properly map to open or close something... its implied based on something 
else before it...  [ ]  are explicit.

STAY was a bad choice. AND was better - the only reason I picked 
AT is because I thought infix was impossible.

but what's the point of AND   everything is already AND by default. 
just put them in a block, so they are and.  when you read & it doesn' 
appear that the parser isn't moving forward.

EITHER doesn't work like EITHER, and it needs to be prefix, and use 
the semantics of Carl's + proposal or it won't work. Suggest a name 
to be used instead.

the only thing he's complaining about is putting things in a block... 
what's the problem with that?

either [] [] []  can't be more explicit thant that... what is the 
problem with blocks?  or a paren for the condition?  really I don't 
get it.

To use a tool it sometimes helps to know how. Assume some basic reading 
of docs will be needed to use a programming language.

This is not the same thing as a programming language conditional 
- it is a GTDPL concept.

... and - I don't buy arguments like - it is a GTDPL concept. Our 
(parse) users will not care about such statements. We are not here 
to adhere to any academic theories, but to make things usefull. If 
we wanted to adhere to what the world uses in parsing area, we should 
go the regular expressions route ...

Do you get that the concept needs a name, and that obscure concepts 
also need names? The standard syntax for this concept won't work 
in REBOL, and the only other comparable parser is the one in Perl 
6, and we can't use that syntax either, or its semantics either (it's 
compiled). This *is* guru stuff - people get PHDs about parsing. 
Carl's proposal for +'s semantics is the way that this has to work 
given how REBOL parsing is implemented.

dang ... I just *got* it...

either  [ a | b ]  [ c ] [ d ]

Maxim, the a's in Carl's examples aren't involved in the expression.

(bts... about the 'a yes I didn't use the same vars in sequence... 
sorry)

[+ a |  b | c] is equivalent to [a b | not a c] but without the overhead 
or side effects being executed.

So, do you have a name for that?

This is really just - EITHER A [b][c], no?

[a b | not a c]   actually it should say... [ [a b] | [not a c]] 
  sorry but the |  doesn't roll back the a it will only roll back 
the b... its bit me too many times

No, because the a is not a condition, it's a rule.

Maxim, the a is rolled back too.

btw - how will you explain it to the user? Maybe it is just too new, 
but unless you provided me with [a b | not a c], I was not able to 
depict [+ a | b | c]

OK, let's try an easy one. Try to explain + without usingh the word 
"addition". Symbols are sed for a reason.

Brian - not, it is you, who can't explain it in fact. You can come 
up with a sensible name for the pattern of usage, so you throw some 
obscure symbol at us :-)

Max - we have to stay with + or some other symbol. If you look at 
examples, there is stuff like [a 2 + b | c | d | e] and I don't think 
any name will fit all usage scenarios.

yes I know ... but we never had a single word which properly explained 
what is going on ... now we do.

When you don't have a descriptive term that covers an idea, you use 
a symbol and tell someone to learn it.

PARSE already has a lot of | symbols, and the operation currently 
proposed to be named | actually ties intto the current semantics 
of those | operations.

... you are just using those excuses. Simply put - if you want STAY 
instead of AND or &, then we will throw it back to you, accusing 
you of the need to change already used | symbol by giving it a name 
:-)

Proposed. Originally, Peta renamed & to AND since he (she?) thought 
that a spelled-out word was required by the dialect. Then I changed 
AND to AT since I didn't know infix operations were possible. Then 
Carl changed AT to STAY, since he didn't see the point. Then he realized 
what the operation meant and changed it back to &, what it should 
have been in the first place since it is the opposite of |.

although for "&" I agree, it really is just a single letter symbol 
which means AND, which in this case is right.

Perl 6 has already surpassed PARSE in its own category: their "regex" 
engine is a PEG parser, and has useful stuff we're adding now.

This seems like a really good candidate for a symbol, but finding 
a prefix one is tough. If it could be postfix we could use ?, or 
even +. Postfix would look like infix, or rather like C's ?: when 
combined visually with the next | character.

I saw BASED-ON as a prefix symbol.

based-on rule | yay | nay

Then [a ? b | c] would be equivalent to [a b | not a c].

I really like, like in the end we are going to decode it for the 
users in documentation - "Now, you parse user, please read following 
syntax as - EITHER rule A is matched, THEN B is evaluated ELSE C 
is valuate" ... yet we will pretend, that we came up with some cool 
symbol to express what we just had to explain in human words :-)

attempts to match a rule, AND runs first rule if it matched OR second 
rule if it did not.

no? how do you explain [a b | not a c] then? I thought that - EITHER 
(IF) A is mathed, then B is being matched, or C is being matched 
(by being matched I mean - evaluated, hence might fail)

but copy actually does copy what is being parsed.  either isn't comparing 
a value like the if PARSE statement.

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.

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

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 :-)

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

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 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 ?

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

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.

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 ...]

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 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 
?

Howerver when you don't know what you can put and what you can skip 
you end with a ugly code full of useless things

actually VID is pretty unstable in R3 ... it's not hard to make the 
VM gets a hardcrash ...

hum i can't tell you what a gob looks like i don't know how to access 
them

vid will not be a default thing anymore ?

The plan is now to do a /Core and /View, with /Core coming out first.

brianh  i know htat what i read on the blog too but i though vid 
would be integrated by default in the VM ... a module is like it's 
external and you don't have it by default

Too much code, too much to keep track of. So, Carl took a break to 
start the module system and I finished it.

i want a way to handle fonts the proper way on all os's and with 
draw . i want a given font to be able to speak with me or the VM 
and draw/text to auto adapt the rendering to it. (if i have to simulate 
a fake cursor i will need to know what is the real pixel size of 
each of the chars in my line;;;)

it would be nice to thing the font system in a modern way ... I'm 
not sure how i can explain that ;;;

seems like a R2 version for Windows 7 might be necessary? is that 
what you mean?

maxim exactly and even the linux rebol VM renderise same font from 
same font file in a different way  and the fixed font caracter is 
not kept at all all fonts become unfied like magic and some time 
along the document produce wrong spacing information

i tested even forcing rebol to use the tff file from windows XP  
and that produced the same sizing bug 

all the text motion turns around the idea you don't have much to 
care about each char size in pixel since it's always the same you 
do a size-text call on "MM" only when you change the font size (growing 
the text shrinking it) and that's all if we had to care about the 
rendering of each elements in the texts that woud be a real pain

we would have a draw/text call for with precise sizing for each and 
every char  making the draw block cliped to our area-tc/effect/draw 
a gigantic size

hello word imagine it as text 0x0 "H" text 0x10 "e" text 0x15 "l" 
text 0x17 "l" text  0x19 "o" and each time you have to retreive the 
precise size (an hash table could be done with char => real_pix_size) 
but then you need anyway a good way to retrieve that size in formation 
being sure it's not a wrong information and size-text  doesn't works 
well on char from unfixed fonts

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

I would like Cyphre to devote 5-10 days to core engine. E.g. transparent 
windows (not absolutly necessary for initial release, just an example) 
is just question of setting particular bit for API call, at least 
under Windows. I would like to see - Unicode, better fonts, cached 
gfx (we don't use bitmap caching yet), eventually switch to AGG compound 
rasterizer, some draw suggestions being implemented - so much for 
a low level ...

Shad: I complained a lot about unview. It has to take some parameter. 
So Unview none, Unview my-win, Unview 'all .... but - what is a big 
deal? Just type help unview in console ;-)

font rendering not taking advantage of AGG i'm completly agree since 
anti aliased doesn't works properly but this should be the time on 
that particular area to see the font rendering area under a new line 
of real time text processing and their is alot  of amazing things 
to be done . 

in the end my request is simple i want my users to choose their own 
font they like on any ot the main OS brands and get the same result 
everywhere (even on online editing for example imagine the rebol.org 
integrating viva-rebol thrue rebol3 webrowser plugin  to allow the 
script sumiters and owner to share editing of a script with bunch 
of select people. That's the qualité we should aim for.)

when you talk about layer that means interfaction a visual area with 
extern library rendered visual contents ?

like cliping a video or a opengl/direct 3D rendered area to a vid 
box.

Pekr can we still keep win32 15 years old kid as base for VID  on 
windows plateform on a middle term  (5 more years) won"t it be better 
to start right now to support winfx enhancement and use part of the 
hardware acceleration in rendering?

i feel  like this being focused on too many targets ( OSes where 
VID exists) make you loose from your sight what are the real interrest 
in coding on one particular OS among the others ..  wanting to be 
too much generic and too few specific gives a bad image to your product 
(that's my own opinion)  if you see port of  other libraries like 
GTK+ or OPEngl  they are ported to act the same way but they include 
 to some very specific plateform related obtimisations and functionalities. 
this should then mean the guy that need a basic set of instruction 
to quick to interfaces GUI forms to a database then rebol crossplatform 
 abilities will allow him to just don't care where his program runs. 
But in some high level area  optimising is 90% of your task  and 
it's a constently evolving task . If we want to bring rebol and VID 
to the Guru level to a solution that make people considere it serriously 
and not like another freak toy for freak kids then it's  obvious 
that area have to be digged up and brought to rebol too

rich-text is read only spécific rendering  based on a specific markup 
language... since we are not talking about the same goal ( i want 
real time text edition (read and write) and the hability to create 
extend or change the rendering process to feet not only colorize 
text but any kind of tet rendering with high performances and simplicity 
of code writing. area-tc is just the first step in that process it's 
just  a proff to show that VID and most largely rebol concept can 
bring to that area. But there is still alot of work to do and that's 
normal initially VID and draw were not designed to handle such duties 
and the tricks we had to use to achieve that goal in R2 only showed 
us the limitation of the existing. So what we do do we evolve to 
chase that area or do we just try to redo again a limited R2  version)

then i think ritch text is based on an old idea replaced by a more 
powerfull one....  based on area-tc way to work redoing the richt-text 
area to bring in it the write cncept is not impossible to be done. 
and what better way for a user to use a markup language not knowing 
you use it (MS word and all other advanced tet editing tools does 
that constently. from RTF to PDF)

you have your wysiwyg tool you write your documentation you push 
a button to generate the documents and store it then you do a view 
[ doc load %./data/doc.mdp ] and that's all

that's thinked to render help documentation in your own GUI  software 
that's not thinked as a document writing tool. you have to use an 
external way to easyly create large formated documentation without 
having to keep in mind the over all markup language

Shadwolf, no, rich text in R3 is also writable. there was a bug a 
while ago that would let you unintentionally edit parts of the DOC 
style. We are just missing parts for logical control of the cursoe 
between different styles in the text and text selection across styles.

i read the scrip it speak to draw directly hading the conversionn 
to markup layer since it's not thought for that purpose will had 
a delay to the engine. I really need to speak directly to draw. that's 
all

you must realize that the format  of a document (encoding of the 
layout) isn't directly  tied to its content.

as long as you can detect what word is under the cursor at a given 
 coordinate using specified scrolling, you could use the rich text 
directly.  and then output to whatever format you want... as long 
as you can predermine how all the coordinates map in both systems. 
 This last part is what just about every importing/exporting out 
there tries to get just right... but in the end, its never exact 
because coordinate systems are different, font rendering engines 
don't use the exact same algorythms, etc, etc, etc.

in R3, all text is rich text, but you don't notice that, since it's 
only really taken advantage of in a few styles.

MD doesnt include images or complexe paragraph formating ... that's 
just a toy

no its like saying I must convert any kind of 3D geometry to any 
rendering engine out there.  Same if we want to export them... a 
model from maya has to be converted to another format if you want 
to use renderman.  all of the scene management is independent of 
the 3D atoms being used.

maxim with an imposed close format and an imposed close black box 
called "doc"  what you gain in a hand you lost it on the other hand 
cause you still have to convert your raw data into the specifiq imposed 
markup language and if that markup language have limitations then 
you have find again new tricks to do what wasn't planned to be done... 
 that's not like choosing your own format and then your own rendering 
line. That's why i said in my example we impose to you the use oof 
XML  sheets to represent your 3D data (which is obviously far to 
be the most performant and the most suited to that use) and you are 
stuck to what the black box is able to do no way for you to directly 
have an impact on the rendering line.

The rich text dialect is a data structure, not a markup language.

[parse "ab"      ["a" either "b" | "c" | "d"]]


How to read it, please? If "a" is being matched, then try to match 
"b", or try to match "c"?

did we ask for too much and unleashed a monster in Carl?  ;-)

also
 would work here. a also b | c

I'm thinking that giving too much fun stuff for Carl to do is scary... 
he should go back to extensions...  or maybe not... he might popup 
a full ANSI C parse rule,  in an hour, just to prove its easier than 
before ;-)

a 'WITH b | c

brian - advanced stuff like [a 2 + b | c | d | e]  still possible?

I am against + sign though. I thought about equivalence of 'then, 
which is sometimes expressed as ==>, hence => or -> would be enough, 
although a bit cryptic. The word 'then is still my favorite ...

I suggest anyone interested, to read example at: http://www.rebol.net/wiki/Parse_Project#Examples
, to see, how it "feels". AND keyword is like an alien from the outer 
space there, and if there would not be comment at the and of the 
line, stating (after fixig a typo): "Back in the same position as 
before the AND.", you would hardly know, what does have AND (most 
often perceived as logical operation) in common to keeping the position 
at original series index? Why not STAY, KEEP, HOLD?

Or do I understand AND meaning incorrectly?

As for EITHER/+, my favorite proposed name for that is now =>. We 
absolutely have to use '| for the second part, since => is *not* 
an infix operation, it just looks like one. Since we can't use 'else, 
'then looks a little silly, as do all alphabetic words when paired 
with a symbol like '|. We need another symbol, and => implies advancement 
without making it seem that the data position is being advanced like 
'next would.

Brian - that makes a difference then ... isn't example comment wrong 
then? "Back in the same position as before the AT."

forget AT, there should be AND, it is a typo. But as I understand 
it, it returns back at initial position?

hmm, so and is not semantically aligned with | ? I mean [a & b & 
c]?

OK, but - we always think about OR vs AND as their logic counterparts. 
Now it is not true, or is it? By our definition:


AND: Purpose: A look-ahead rule: Matches the parse rule without changing 
the current position. 


I am denerved about the "without changing the current position" part. 
It is some explicit rule user will have to know. Why not to advance 
the position?

All of these are rules the user will need to know. It's a programming 
language, not baby talk.

AND block! into rule - does mean - check if the next match is being 
a block, but don't advance. And if so, go into rule? If so, then 
AND is totally weird name ...