AltME groups: search

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

Icarii, your svg file is too much complicated for me.

It's using both gradientUnits="objectBoundingBox" and gradientUnits="userSpaceOnUse" 
 to render the gradients.

userSpaceOnUse

 use real coordinates for the vectors used by gradients (what i do 
 currently).
objectBoundingBox

  use % vectors which have to be converted into real unit,  depending 
  of the real size of the object (after rendering) where the gradient 
  is applied (what the fuck  !!! it's magic).


I have enough pain to construct correct gradients in real units for 
the moment.Your svg file is too much complicated.

and, BTW, "construct" and "constructor" does not have the same meaning 
for me

moreover, the #[...] constructs are actually executed by the LOAD 
function (or maybe Transcode,...) internally, which may call whatever 
functions it likes to construct any specific datatype represented 
by the discussed #[...] text, but this does not make the "#[...]" 
text a function, anyway

it has nothing to do with the lexical analyser, we just need a new 
data type, to construct computed variables

** Hint
Currently there is problem to complement charsets in R3.

To have 256 values in the complement (like in R2), I add the char 
#"^(FF) in the charset:
c: complement charset "0123456789^(FF)"


But it's not exactly the same thing (cause the value 255 is not allowed 
in the complement).

Have you any idea to have the "exact" complement (without using a 
nasty loop to construct the bitset!) ?

you can with R3
>> set c: construct [a: b:] [3 5]
== [3 5]

>> c
== make object! [
    a: 3
    b: 5
]

steeve, contexts usually contain much more than that, so CONSTRUCT 
is very limiting here.

As for where the right place to put the CGI environment variables, 
R3 currently leaves them in the environment, and uses GET-ENV to 
get at them. When system/options/cgi was first created, REBOL didn't 
have a user-accessible GET-ENV function. You could easily write a 
REBOL function that could construct an object containing all of the 
information passed to a CGI process, but that function and that object 
would be web-server-specific.

when i construct an event! with something like:
>> make even! [type: 'minimize gob: my-gob port: port-event]

i got:
** Script error: cannot set gob: field to gob! datatype

Wtf, i can't set the gob field with a gob ??????

I am a parse beginner. I always proposed to/thru [a | b], but then 
I took Gabriele's suggestion to my mind and started to construct 
parse rules different way. What caused biggest problem for me as 
for beginner, was nested/recursive calls, and not separated local 
contexts ....

Henrik - in Carl's proposal, imo no performance hit. It simply tells 
parse that new limit for next rule evaluation is XY chars/bytes? 
It just could make you lazy in that manner, that you will not construct 
proper rules, but e.g. knowing that your tel-number is 8 chars long, 
you just limit it, as you can be sure about it.

Again about parse, there was that proposal to execute words bunded 
with functions and to parse their result instead of doing nothing 
currently.
It would allow to construct dynamic rules.
Any opinion ?

Well, i only wanted construct a block of tags and strings.
So i came with that, it's enough for me currently.

src: read %frog.svg
out: []
parse src [
	any [
		copy str to [#"<" | end]
		opt [if (not empty? str) (append out to-string str)]

  not end src: (set [data src] transcode/next src append out data) 
  :src
	]
]

yes a dialect to construct schemes

There was a suggestion that SWITCH treat certain words as keywords, 
translating them to their standard values, in particular logic! and 
datatype! keywords. This would make SWITCH work like CONSTRUCT, and 
would likely require an /only refinement for the non-keyworded behavior 
like CONSTRUCT has. This would add a little overhead to SWITCH, but 
not as much as the workaround code already adds. The question hasn't 
yet been resolved, and should be brought up again for final resolution 
- some mezzanine code would need revising.

I want to use anything that is out there... your service is a low-level 
construct I can surely leverage... I'll probably add a few refinements 
to it when I finish the caching engine... right now I'm dealing in 
other  lower-level remark internals.

I seems I need to construct a RX string and set every single char?

Each app choses its own IPC when the OS doesn't have one standard. 
 No single IPC method will be usefull.   


for REBOL itself, I do think that we should provide a construct which 
will be similar or exactly the same as what will be build for thread 
messaging.

And then you've got to properly construct the block in b :)

REBOL doesn't have pointers, it has references, and it doesn't have 
addresses. So the only way you could legitimately get a pointer is 
to return it from a command. But you don't want to have any way to 
construct an illegitimate pointer in REBOL and pass it to a command 
because that would be a much worse security and stability problem 
than just having commands at all, and treating pointers as integers 
lets you do that. So there is the handle! type to store pointers. 
A handle! is an immediate value that is the size of a pointer, but 
that you can't convert directly to or from any other value, or even 
mold it to see its contents. When you return a pointer from a command 
you set the value to the handle! type. Then that handle! will be 
usable when passed back to other commands in the same extension, 
and maybe even when passed to other extensions, depending on address 
space issues. Handles are also used to store function pointers in 
R3, and other opaque system values like library addresses.

offered by:
	TomBon
Task:

 R3 - Bindings for a KNNL - SOM (Self-organizing map) /Kohonen Network
	http://knnl.sourceforge.net/

	API - http://knnl.sourceforge.net/html/index.html

	Further Readings:
	http://en.wikipedia.org/wiki/Self-organizing_map
	http://www.ifs.tuwien.ac.at/dm/somtoolbox/
	http://accu.org/index.php/journals/1378
	http://www.codeproject.com/KB/graphics/som.aspx

	Alternativ:
	Quick Tutorial on how to construct a SOM.
	Perhaps to create a modul directly in R3?
	http://www.ai-junkie.com/ann/som/som1.html


Amount:
	$350
Valid until:
	01.04.2011
Terms:
	PayPal

it appears to me that if all the properties of the header was kept 
as strings.
then we could construct back the header's response with 
>>enline form headers
(no need to make a foreach anymore)

and i will use a dialect to construct the state diagrams

I've spent a bit of time going over R3/View and believe it now has 
all the "building blocks" required to build a modern/fast gob! based 
GUI. The amazing thing is that these building blocks are the 10 natives 
that View adds [to Core]. They are:

	gob!
	caret-to-offset
	cursor
	draw
	effect
	map-event
	map-gob-offset
	offset-to-caret
	show
	size-text


With these 10 natives (gob! is actually a type!) we should be able 
to construct simple but powerfull gob!-based GUIs with a smaller 
mezz footprint than R2. My preliminary conversion of RebGUI to R3 
seems to take about 50% the code to do the same thing [compared to 
R2] ... very promising at first glance.


To get a feeling for how tight the code can be the next post is the 
entire [skeleton] source of a working gob!-based GUI.

About my DISABLED it's true that i'ts only usefull at the construction. 
I.E When You want to construct a pannel from an existing one.

and i don't like the need of  a phase to construct graphical objects 
from read-only specs.
All the GUI we had so far, act such.
It's an bad...

Is there some easy way of of hot obtain list of available styles? 
Are styles somehow divided upon internal (thsoe are more of classes 
you use to construct other styles) and user useable styles?

If you are talking about user input, then it is best to parse and 
construct. That way any errors can be flagged.

frame! is used in extensions as well. There It's a linked/cascaded 
data-structure to get access to call parameters and construct return 
values like block!

I built my own decoder for the query-string and it works pretty good. 
 But I was wondering what the /only refinement is for  construct. 
 This looks new in R3.

CONSTRUCT by default translates the built-in logic words to logic 
values, unset values to none, lit-words to words, and lit-paths to 
paths. This makes it easier to use it to handle headers. CONSTRUCT/only 
doesn't do any of those things - it only constructs the object with 
the data provided.

Also, thanks for the explanation Brian, I see you answered my question 
regarding Construct.

do we really want this behavior:

>> obj: construct [a: b: c: 1]
== make object! [
    a: 1
    b: 1
    c: 1
]

And CONSTRUCT doesn't evaluate anything, so safety is not an issue.

Still we need to check it and we could simply have another switch 
that could fix construct to be even more superior.

construct/as-is

>> a: construct/only [c: d: 1]
== make object! [
    c: 1
    d: 1
]

>> construct/only [a: b:]
== make object! [
    a: none
    b: none
]

Ok, it doesn't seem your following me, so let's forget about construct.

So it would be similiar to construct except without the chain assignment.

Ideally you would use a construct for assignments of values passed 
via cgi.

If the CGI data is parsed properly it should never generate anything 
other than pairs. If it ever generates chained assignments that is 
an error in your parse rules, not CONSTRUCT.

That was this one:

>> a: construct [b: c: 2]
== make object! [
    b: 2
    c: 2
]

Just so that we can do some dynamic building of blocks with set-words 
and pass it to construct and not worry about a set-word getting assigned 
a value from the chain.

Paul, just iterate through the block before you construct it and 
whenever a set-word! is followed by another set-word! insert a none 
in between.

Chris, I had an issue where I was putting data into a block dynamically 
and then had a skip pattern over it so that every other word was 
turned into a set-word and then passed to construct.

The point isn't about whether or not I can do that.  I already do. 
 The point is that it offers more for the construct function to do 
at what I believe would be less cost with more to gain.

Paul what you are asking is that the construct function should rather 
arbitrarily rewrite the block argument it is passed.

construct/as-is [a: b: 2]

Paul, you're basically asking for REBOL to do a fundamental change 
to its syntax inside construct.

with 2 blocks it's easy, one for the definition, one for the assignement.

>> assign: funco [spec vals][append construct spec vals]
>> assign [a: b: c: d:][c: 2]
== make object! [
    a: none
    b: none
    c: 2
    d: none
]

Am I asking for the construct code to be change - duh!

The code in construct would have to parse the block

I guess that's what you want. Now adding that as refinement to construct 
is a question of wether it would be of general utility. If not, it 
would just be bloat.

My point is that if we just adding your entire function to R3 verse 
a refinement to construct - we would be adding MORE bloat

Paul, construct is using standard REBOL syntax in this case. If that 
is a safety concern for your purposes, that's outside the scope of 
CONSTRUCT.

I don't know of a construct refinement that drops all strings.

I vote against the proposed change to CONSTRUCT. I believe the need 
is better served with a mezz. If it becomes popular and useful, then 
consider making it part of the standard distro.

Sunanda/Andreas/BrianH: check my comment to the CC #1506 containing 
a B-CATCH/B-THROW example of a dynamic construct allowing an "in 
time detection" of unhandled throw

and sometimes i use this trick too.

context [
  a: construct reduce/no-set [
     parent: self
  ]
]

CONSTRUCT's /only means /no-tricks, for instance.

You can do that now: The hidden 'self is overriden, and the 'self 
trick doesn't apply. Like this:
; Current behavior: 
>> a: construct [] 
== make object! [ 
] 
>> append a [self: 1] 
== make object! [ 
self: 1 
] 
>> do bind [self] a 
== 1 
>> protect/hide in a 'self 
== self 
>> do bind [self] a 
== make object! [ 
] 
>> same? a do bind [self] a 
== true

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.

the word "thread" makes me think too much of the low level thread 
management that you typically do when that is the only concurrent 
programming construct

Here's a low-level function to parse and process script headers, 
which shows how many features are built into the base script model 
in R3:

load-script: funct [
	"Decode a script into [header-obj script-ref body-ref]"

 source [binary! string!] "Source code (string will be UTF-8 encoded)"
	/header "Return the header object only, no script processing"

 ;/check "Calculate checksum and assign it to the header checksum 
 field"
	/original "Use original source for Content header if possible"
] compose [
	data: either string? source [to-binary source] [
		unless find [0 8] tmp: utf? source [ ; Not UTF-8
			cause-error 'script 'no-decode ajoin ["UTF-" abs tmp]
		]
		source
	]

 ; Checksum all the data, even that before the header or outside the 
 block
	;sum: if check [checksum/secure data]  ; saved for later
	
	if tmp: script? data [data: tmp] ; Find the start of the script
	
	; Check for a REBOL header
	set/any [hdr: rst:] transcode/only data
	unless case [
		:hdr = 'rebol [ ; Possible REBOL header
			set/any [hdr rst] transcode/next/error rst
			block? :hdr ; If true, hdr is header spec
		]
		:hdr = [rebol] [ ; Possible script-in-a-block
			set/any [hdr rst] transcode/next/error rst
			if block? :hdr [ ; Is script-in-a-block
				unless header [ ; Don't decode the rest if /header
					data: first transcode/next data
					rst: skip data 2
				]
				true
			] ; If true, hdr is header spec
		]
	] [ ; No REBOL header, use default
		hdr: [] rst: data
	]
	; hdr is the header spec block, rst the position afterwards

 ;assert/type [hdr block! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]
	
	; Make the header object, or fail if we can't

 unless hdr: attempt [construct/with :hdr system/standard/header] 
 [
		cause-error 'syntax 'no-header data
	]
	; hdr is a correct header object! here, or you don't get here

 ;if check [append hdr 'checksum  hdr/checksum: sum]  ; calculated 
 earlier

 ;assert [sum =? select hdr 'checksum]  ; Should hdr/checksum be reserved?
	

 if header [return hdr] ; If /header, no further processing necessary

 ; Note: Some fields may not be final because post-processing is not 
 done.
	
	; Skip any whitespace after the header

 ws: (charset [1 - 32]) ; For whitespace skipping (DEL not included)
	if binary? rst [parse rst [any ws rst:]] ; Skip any whitespace
	
	; Check for compressed data and decompress if necessary
	case [
		; Magic autodetection of compressed binary
		tmp: attempt [decompress rst] [
			data: rst: tmp  ; Use decompressed data (no header source)
			append hdr 'compressed  hdr/compressed: true ; Just in case
		]
		; Else not directly compressed (without encoding)
		(select hdr 'compressed) != true [] ; Not declared, do nothing
		; Else it's declared to be compressed, thus should be
		binary? rst [ ; Regular script, check for encoded binary
			set/any [tmp rst] transcode/next/error rst
			either tmp: attempt [decompress :tmp] [
				data: rst: tmp  ; Use the decoded binary (no header source)
				hdr/compressed: 'script  ; So it saves the same way
				; Anything after the first binary! is ignored
			] [cause-error 'script 'bad-press -3] ; Else failure
		]
		; Else it's a block, check for script-encoded compressed binary
		tmp: attempt [decompress first rst] [

   data: rst: tmp  hdr/compressed: 'script  ; It's binary again now
		]
		; Else declared compressed but not compressed, so fail
		'else [cause-error 'script 'bad-press -3]
	]
	
	; Save the script content in the header if specified
	if :hdr/content = true [
		hdr/content: either original [source] [copy source]
	]
	

 ;assert/type [hdr object! data [binary! block!] rst [binary! block!]]
	;assert [same? head data head rst]

 reduce [hdr data rst]  ; Header object, start of source, start of 
 body
]


Note all the commented assert statements: they are for testing (when 
uncommented) and documentation. Also, I later removed the checksum 
calculation from this code because it was the wrong place to put 
it, at least as far as modules are concerned. However, Carl didn't 
know this because he was working on it while I was offline for a 
few days.

Here is the corresponding function in the code reorg, renamed. The 
friendly empty lines and comments haven't been added yet.

load-header: funct/with [
	"Loads script header object and body binary (not loaded)."

 source [binary! string!] "Source code (a string! will get UTF-8 encoded)"

 no-decompress [logic!] "Skip decompression of body (because we want 
 to look at header mainly)"
][
	; This function decodes the script header from the script body.

 ; It checks the 'checksum, 'compress and 'content fields of the header.

 ; It will set the 'content field to the binary source if 'content 
 is true.

 ; It will set the 'compress field to 'script for compressed embedded 
 scripts.

 ; If body is compressed, it will be decompressed (header required).

 ; Normally, returns the header object and the body text (as binary).

 ; If no-decompress is false and the script is embedded and not compressed
	; then the body text will be a decoded block instead of binary.
	; Errors are returned as words:
	;    no-header
	;    bad-header
	;    bad-checksum
	;    bad-compress
	; Note: set/any and :var used - prevent malicious code errors.
	case/all [
		binary? source [data: assert-utf8 source]
		string? source [data: to binary! source]
		not data: script? data [return reduce [none data]] ; no header

  set/any [key: rest:] transcode/only data none ; get 'rebol keyword

  set/any [hdr: rest:] transcode/next/error data none ; get header 
  block

  not block? :hdr [return 'no-header] ; header block is incomplete

  not attempt [hdr: construct/with :hdr system/standard/header][return 
  'bad-header]

  :hdr/content = true [hdr/content: data] ; as of start of header (??correct 
  position??)
		:key = 'rebol [ ; regular script

   rest: any [find rest non-ws rest] ; skip whitespace after header

   ;rest: any [find rest #[bitset! [not bits #{7FFFFFFF80}]] rest] ; 
   skip whitespace
			case/all [

    all [:hdr/checksum :hdr/checksum != checksum/secure rest] [return 
    'bad-checksum]

    no-decompress [return reduce [hdr rest]] ; decompress not done

    :hdr/compress = 'script [set/any 'rest first transcode/next rest]
			] ; rest is now suspect, use :rest
		]

  :key = [rebol] [ ; embedded script, only 'script compression supported
			case/all [
				:hdr/checksum [return 'bad-checksum] ; checksum not supported

    no-decompress [return reduce [hdr rest]] ; decompress not done

    rest: skip first transcode/next data 2 none ; decode embedded script

    :hdr/compress [hdr/compress: unbind 'script  set/any 'rest first 
    rest]
			] ; rest is now suspect, use :rest
		]

  :hdr/compress [rest: attempt [decompress :rest]] ; :rest type-checked 
  by decompress

  not :rest [return 'bad-compress] ; only happens if above decompress 
  failed
	]

 ;assert/type [hdr object! rest [binary! block!]] ; just for documentation
	reduce [hdr rest]
][
	non-ws: charset [not 1 - 32]
]

Notes:

- The other half of the CASE/all style is a lot of explicit shortcut 
RETURN statements, whenever the normal flow differs.

- Errors are returned as a word from the error catalog, which is 
later passed to CAUSE-ERROR.

- Carl redid the checksum calculation so that scripts can verify 
against a checksum in their header, to detect corruption.

- The checksum in the header probably can't be used for the module 
checksum because the header itself matters for modules.

- Compressed scripts lost a couple minor, unimportant features that 
we are likely better without. Quiz: What features?

- Part, but not all of the reason the code is shorter is because 
the doc comments haven't been added yet. The CASE/all style helps 
though.

Yes Maximn, to do runtime debugging, we must be allowed to construct 
observable functions

Maybe you can try
to-decimal #{ ... 16 digits ... }

If that still works, you can use it to test, what you get, when you 
construct numbers like NaNs. To see how REBOL3 handle it.

...and it surely does not make sense to call #[map! [...]] a "serialized 
constructor" - it is just a syntactic "construct" used as data by 
something.

Any info about the algorithms used to construct and perform lookup 
on symbol's tables in R3 ?
People gave some hints back in the day.
But I can't remember who.

actually that's a construct I miss....

eg. in dbase we had

do loop [ ............ ] endloop or something like that.


but you could exit anyway inside that block to restart the loop like 
this

do loop [ .... loop .... ] endloop

Of course, this construct is just for R2, for R3 you have native 
solution

That you think it's not implemented in any loop construct (even under 
a different name) ?

I explain it for RETURN, but the case of THROW is similar. Normally, 
when you use RETURN in REBOL, it is a global function that does something. 
I demonstrated, that it is possible to have a similar construct (possibly 
even using the same name), which could work as "local" in the sense, 
that it would be assigned to a locally-bound 'return word. Such a 
"local RETURN" would, in fact, be able to "jump many levels up", 
not just one level, as the current global RETURN does, since it would 
be tied to its "function of origin".

(or, be careful, and use the copy [...] construct)

The data exchange dialect is a good point to have constructs. Then 
my logic goes:


REBOL values can be divided in two groups, 1. the ones with a non-ambigious 
lexical representation and 2. the ones without such lexical representation. 
Datatypes of values in the second group include:


unset! none! logic! bitset! image! map! datatype! typeset! native! 
action! routine! op! function! object! library! error! port! event!

and maybe a few more depending on what version of REBOL. The rest 
is in the first group.


It would make sense to have constructs for the values in the 2nd 
group. Then I look at some examples of constructs:

#[string! "abc"] #[email! "[abc-:-d]"]


Those are not necessary. If it's because all values can be represented 
as constructs, then why doesn't this work?

>> #[integer! 1]
** Syntax Error: Invalid construct -- #[


And how would values of type native!, action!, op!, etc. be represented 
as constructs?

I'm not convinced.

All you have to do is construct a correct inner function, instead 
of an erroneous one.

One construct for dynamic scoping is sufficient.

Not to mention, that (break) is not a parse construct, it is actually 
foreign to parse

(and make no mistake, I mean the parse keyword, not the foreign (break) 
construct)

You can not refer to structures by name in lexically scoped constructs, 
when those names are resolved at runtime. Well, you can, but then 
that becomes a dynamically scoped flow construct.
For instance:
a: [break]
b: [while a]


The word 'a is in the lexical scope of b, but the contents of a are 
in its dynamic scope only if b is used as a parse rule at runtime 
and a is still assigned that value. So even though the break is a 
keyword, the scope to which it breaks is the while, which is in b.

...which proves, that break breaks out from A actually, i.e. from 
the lexically closest construct

Yeah, that break thing, I forgot: An interesting thing about PARSE 
was revealed during the course of implementing the parse proposals. 
It turns out that what most people (including me) thought about PARSE 
was wrong. ANY, SOME and WHILE aren't the only loops in PARSE for 
BREAK to break out of: Every rule is a loop. Even rules that don't 
have any iteration or repetition are effectively a LOOP 1. This means 
that while the *scope* of the BREAK operation in PARSE is definitely 
dynamic in its implementation (this also came out in discussions 
with Carl, though it doesn't use the unwind method), it is (afaik) 
impossible to construct a working example of BREAK that demonstrates 
this. I would love it if you could figure out how to write example 
code to prove this, Ladislav, since I've just been taking the author's 
word for it.

...and, the biggest disadvantage of the dynamic return is the opposite 
- the fact, that knowing the lexically closest catching construct 
does not tell you, which construct will be the closest one at run 
time

I just realized something: You don't need word references to have 
the full power of PARSE, you can use circular direct references instead. 
Of course you can't specify those structures in loadable source, 
you have to construct them dynamically, and you can't BIND them so 
you stiff can't use definitional scope for its operations. But it 
is at least in theory possible to match the patterns that finite 
nested rules can't match by using circular structures.

so far, the syntactical rules for rebol scripts.



https://docs.google.com/document/pub?id=1kUiZxvzKTgpp1vL2f854W-8OfExbwT76QUlDnUHTNeA


(Not produced the transcode rule though)

But it's enough to perform the prefetch of a document and to construct 
the internal representation.

I remember that we had a similar problem many years ago when the 
standard GNU software that we incorporate started generating such 
a construct in new versions of the toolchain. I think our solution 
was a quick hack, so on the one hand we can load a lot of current 
software, but on the other hand it is also fairly easy to upset our 
loader

I'm about to define names for them. :-) They were the most practical 
way to construct a dialect that results in proper settings for filling 
or fixating a box cell

OK, so if I understand it correctly, Red/System loads the library 
at an executable load time, whereas load/library does so dynamically 
in the app run-time. Stil - I wonder, if we could get a handle to 
such a library? I mean, syntactically #import is just like preprocessor 
construct - you can't assign it to any variable. Not sure it would 
be usefull, to be able to retrieve a handle to such wrapped library 
plus handles (entry points) to wrapped function calls?

Also, the plan for me since the beginning was to use Red to help 
construct dynamically Red/System programs without requiring any preprocessor. 
As Red is not ready yet, I'm glad we have the preprocessor now in 
Red/System, to make our life easier.

One question towards library wrapping and type casting. One DLL function 
is defined as:

typedef bool (WINAPI *LSN_OPENCARD)(void);//open led card 


When I defined the return type of wrapper funciton as LOGIC!, it 
was always true. When I defined it as an integer, it was either 1, 
or some really high integer number. So i took Cyphre's advice towards 
R2's interface, and in R2 I used CHAR, and in Red/System, I used 
BYTE! type.


Pity construct of a type return: "as integer! [byte!]" is not allowed, 
but at least I now get correct result - 0, or 1, in my print statement, 
where I do: print [as integer! led-open-card lf]


So my question is - why using Red/System's LOGIC! did not work? Is 
C level BOOL a clearly defined type, or can it be defined in various 
ways, so I can't say, that I can automatically use LOGIC! = BOOL 
logic, when wrapping stuff?