AltME groups: search

Is it really a good idea to go deep into R3, with the situation?

this is failing       face: make guie/face [
        options: opts
        facets: make copy/deep styl/faced make styl/facets opts
        tags: copy styl/tags
        state: make guie/face-state select styl 'state
        intern: styl/intern
    ]

But believe me there is a deep gap between what the standard documentation 
teaches and what should be written there to fully understand not 
only objects but the full ideology behind REBOL.

make-char-elements: func [name count /local result][
    result: copy []
    loop count [insert tail result reduce [:name [char!]]]
    result
]


OSVERSIONINFO: make struct! compose [
    OSVersionInfoSize [integer!]
    MajorVersion      [integer!]
    MinorVersion      [integer!]
    BuildNumber       [integer!]
    PlatformId        [integer!]
    (make-char-elements 'CSDVersion 128)
] none
OSVERSIONINFO/OSVersionInfoSize: length? third OSVERSIONINFO


;-- Requires NT 5.0 (NT4 SP6) or later
OSVERSIONINFOEX: make struct! compose [
    OSVersionInfoSize [integer!]
    MajorVersion      [integer!]
    MinorVersion      [integer!]
    BuildNumber       [integer!]
    PlatformId        [integer!]
    (make-char-elements 'CSDVersion 128)
    SvcPackMajor      [short]
    SvcPackMinor      [short]
    SuiteMask         [short]
    ProductType       [char!]
    Reserved          [char!]
] none
OSVERSIONINFOEX/OSVersionInfoSize: length? third OSVERSIONINFOEX


;---------------------------------------------------------------

lib: load/library %kernel32.dll

GetVersion: make routine! compose/deep [
    lpVerInfo [struct! [(OSVERSIONINFO)]]
    return: [integer!]
] lib "GetVersion"

GetVersionEx: make routine! compose/deep [
    lpVerInfo [struct! [(OSVERSIONINFOEX)]]
    return: [integer!]
] lib "GetVersionExA"


; load the OS version info data.
OSVI: OSVERSIONINFOEX
if 0 = GetVersionEx OSVI [
    OSVI: OSVERSIONINFO
    GetVersion OSVI
]

free lib

;---------------------------------------------------------------

get-CSDVersion: func [OSVer-struct [struct!]] [
    trim/tail to string! copy/part at third OSVer-struct 18 128
]

ExInfoAvailable?: equal? third OSVI third OSVERSIONINFOEX


OSPlatform: [
    0 Win32s    ; Win32s Win32s on Windows 3.1.
    1 Win32     ; Win32 on 95, 98, SE, or Me.
    2 WinNT     ; WinNT Win32 on Windows NT.
]

major-ver: OSVI/MajorVersion
minor-ver: OSVI/MinorVersion

major-ver?: func [val [integer!]] [major-ver = val]
minor-ver?: func [val [integer!]] [minor-ver = val]


PlatWin32s?: does ['Win32s = select OSPlatform OSVI/PlatformId]
PlatWin32?:  does ['Win32  = select OSPlatform OSVI/PlatformId]
PlatWinNT?:  does ['WinNT  = select OSPlatform OSVI/PlatformId]

Win95?: does [all [PlatWin32?  major-ver? 4  minor-ver? 0]]
Win98?: does [all [PlatWin32?  major-ver? 4  minor-ver? 10]]
WinMe?: does [all [PlatWin32?  major-ver? 4  minor-ver? 90]]

WinNT?: does [all [PlatWinNT?  major-ver <= 4]]
WinNT351?: does [all [PlatWinNT?  major-ver? 3  minor-ver? 51]]

Win2K?: does [all [PlatWinNT?  major-ver? 5  minor-ver? 0]]
WinXP?: does [all [PlatWinNT?  major-ver? 5  minor-ver? 1]]

WinServer2003?: does [all [PlatWinNT?  major-ver? 5  minor-ver? 2]]

Hmm, installers, default dirs, etc., that's kind of deep topic :-)

and when you start a rebol console .. you end up deep in user documents 
somewhere ...

BrianH - but when user script is run, REBOL changes current dir to 
that of the script placement, no? And the script might require to 
create some file at that destination. I know that temp files will 
go to some deep cache dir, but what if script wants to write to the 
dir of the script placement?

but when I say forced, I don't mean spread up all around the disk 
and forgotten on uninstalled, untraceable deep paths, masked by the 
explorer, and even translated on top of it.

brian, true.  my error... I'm deep in calculus... my brain is a bit 
mushy ;-)


IIRC the RFC has an BNF-style breakdown, so there should be no surprise 
as to where hexing can and should be interpreted.

this whole project is fun... I haven't done any ASM since my Amiga 
days... 17 years ago... I'm remembering stuff I had placed in a deep 
black hole in my mind...  :-)

also note that I gave this example as a Draw, since we can all quickly 
see what is happening, but the above applies to many other datasets 
which are used libs, and for which objects are much more user-friendly 
than objects.


think of C libs which use deep struct trees. I'd rather keep the 
user interface object related.

I'm hip deep in it right now...  I'm implementing the last "feature" 
which is the ability to format command arguments differently than 
the original C function parameters.


this will allow templating for extensions, just like in C++, and 
will also allow us to put litterals in the spec, so that one doesn't 
need to provide ALL parameters from the REBOL side.

hip deep = 50% done?

Nasa's deep space one IPC library http://www.cs.cmu.edu/~IPC/

Seems the standard functions are overloaded somehow even when you 
writes your own, (because you want different functionality of course) 
aah deep lake, deep lake

see if you can use COPY , COPY/part , COPY/deep as an alternative 
for READ

ctx-rebgui3: make object! [

	cursors: make object! [
		app-start: 32650
		hand: 32649
		help: 32651
		hourglass: 32650
		arrow: 32512
		cross: 32515
		i-shape: 32513
		no: 32648
		size-all: 32646
		size-nesw: 32643
		size-ns: 32645
		size-nwse: 32642
		size-we: 32644
		up-arrow: 32516
		wait: 32514
	]

	colors: make object! [
		page: white
		edit: white
		text: black
		true: leaf
		false: red
		link: blue
		theme: [165.217.246 0.105.207 0.55.155]
		outline: [207.207.207 160.160.160 112.112.112]
	]

	metrics: make object! [
		cell: 4
		gap: cell * 2
		line: cell * 5
		margin: cell * 4
		margin-size: as-pair margin margin
		radius: 2
	]

	;	Private functions

	set 'make-gob make function! [[

  spec [block!] ; offset, size and one or more attribute/value pairs
		/data object
		/local size text gob axis
	][
		size: spec/2
		if any [negative? size/x negative? size/y] [
			text: select spec 'text
			all [block? text text: first find text string!]

   size: 8x4 + size-text make gob! compose [size: 9999x9999 text: (text)]
			all [negative? spec/2/x spec/2/x: size/x]
			all [negative? spec/2/y spec/2/y: size/y]
		]
		gob: copy []
		;	attributes are (text, color, effect, image and draw)
		foreach [attribute value] spec [
			switch attribute [
				box [
					attribute: 'draw
					value: compose [
						pen (get value/1)
						line-width 1
						fill-pen (get value/2)
						box 0x0 (spec/2 - 1x1) (metrics/radius)
					]
				]
				pill [
					attribute: 'draw
					axis: either spec/2/x >= spec/2/y [2] [1]
					value: compose/deep [
						pen (colors/outline/3)
						line-width 1

      grad-pen linear (spec/2/:axis * .1) (spec/2/:axis * .9) (all [axis 
      = 2 90]) [(colors/outline/1) (white) (colors/outline/1)]
						box 0x0 (spec/2 - 1x1) (metrics/radius)
					]
				]
			]
			append gob reduce [attribute value]
		]
		spec: gob

  gob: make gob! compose [offset: spec/1 size: spec/2 (to set-word! 
  spec/3) spec/4 data: (make object! any [object copy []])]
		foreach [attribute value] skip spec 2 [

   append gob make gob! compose [offset: 0x0 size: spec/2 (to set-word! 
   attribute) value]
		]
		gob
	]]

	;	Public functions

	set 'display make function! [[
		title spec

  /local gob xy max-x max-y left-to-right? after-count after-limit 
  here arg append-widget widget last-widget word
		action
		handler
		size
		text
		color
	][
		xy: metrics/margin-size
		max-x: xy/x
		max-y: xy/y
		left-to-right?: true
		after-count: 1
		after-limit: 9999
		
		gob: make gob! compose [text: (title) data: (make object! [])]

		append-widget: make function! [[][
			unless widget [exit]
			unless handler [

    handler: compose/deep [on-down: make function! [[event][(action)]]]
			]
			append gob switch widget [
				bar [

     make-gob compose [(xy) (as-pair max-x - metrics/margin 1) color (colors/outline/3)]
				]
				button [
					all [none? size size: 15x5]

     make-gob/data compose/deep [(xy) (size * metrics/cell) pill none 
     text [center (text)]] handler
				]
				text [
					all [none? size size: 15x5]

     make-gob/data compose/only [(xy) (size * metrics/cell) color (white) 
     text (text)] handler
				]
			]
			last-widget: last gob/pane
			;	1st reverse item?
			unless left-to-right? [

    last-widget/offset/x: last-widget/offset/x - last-widget/size/x
			]
			xy: last-widget/offset
			;	max vertical size
			max-y: max max-y xy/y + last-widget/size/y
			;	horizontal pos adjustments
			all [
				left-to-right?
				xy/x: xy/x + last-widget/size/x
				max-x: max max-x xy/x
			]
			;	after limit reached?
			either after-count < after-limit [
				;	spacing

    xy/x: xy/x + either left-to-right? [metrics/gap] [negate metrics/gap]
				++ after-count
			] [
				xy: as-pair metrics/margin max-y + metrics/gap
				after-count: 1
			]
			all [:word set :word last-widget]
			word: widget: action: handler: size: text: color: none
		]]


  parse reduce/only spec [after bar button handler return reverse rich 
  text] [
			any [
				opt [here: set arg paren! (here/1: do arg) :here] [
					'return (
						append-widget
						xy: as-pair metrics/margin max-y + metrics/gap
						left-to-right?: true
						after-limit: 9999
					)
					| 'reverse (
						append-widget
						xy: as-pair max-x max-y + metrics/gap
						left-to-right?: false
						after-limit: 9999
					)
					| 'after set arg integer! (
						;	return unless this is first widget
						if widget [
							append-widget
							xy: as-pair metrics/margin max-y + metrics/gap
						]
						after-count: 1
						after-limit: arg
					)
					| 'handler set arg block! (handler: arg)
					| 'rich set arg block! (text: arg)
					| [set arg integer! | set arg pair!] (size: arg)
					| set arg string! (text: arg)
					| [set arg tuple! | set arg none!] (color: arg)
					| set arg block! (action: arg)
					| set arg set-word! (append-widget word: :arg)
					| set arg word! (append-widget widget: arg)
				]
			]
		]

		append-widget
		gob/size: metrics/margin-size + as-pair max-x max-y
		gob/offset: system/view/metrics/work-size - gob/size / 2
		append system/view/screen-gob gob
		show system/view/screen-gob
	]]

	set 'undisplay make function! [[gob][
		remove find system/view/screen-gob gob
		show system/view/screen-gob
	]]

	;	Start global GUI event handler

	active-gob: none
	system/view/event-port: open [scheme: 'event]

 system/view/event-port/awake: make function! [[event /local evt gob][
		evt: map-event event
		gob: evt/gob
		while [not object? gob/data] [gob: gob/parent]
		if all [event/type = 'move gob <> active-gob] [
			attempt [active-gob/data/on-away event]
			active-gob: gob
			attempt [active-gob/data/on-over event]
		]
		evt: to word! ajoin ['on- event/type]
		attempt [gob/data/:evt event]
	]]
]

add a closing ']'. An example app is:

blk: copy []
foreach word words-of ctx-rebgui3/cursors [
	append blk compose/deep [
		text (form word) handler [

   on-over: make function! [[event][cursor (ctx-rebgui3/cursors/:word)]]

   on-away: make function! [[event][cursor ctx-rebgui3/cursors/arrow]]
		]
	]
]

display "Test Window" compose [
	text 83x10 rich [size 36 center red "Reb" black "GUI" leaf "3"]
	after 5
	(blk)
	return
	bar
	reverse
	button "Close" [undisplay event/gob]
	button "Open" [
		display "Alert" [
			after 1
			text 50x5 "Some more text."
			bar
			reverse
			button "Close" [undisplay event/gob]
		]
	]
]

Got caret working, but it's overly complex IMHO, as in:

s: "A bit of text."

c: make object! compose/deep [
	caret: copy [[(s)] (tail s)]
	start: copy [[(s)] (at s 3)]
	end: copy [[(s)] (at s 6)]
]


show append clear system/view/screen-gob make gob! [text: [s caret 
c]]

just copy/deep the style :-)

copy/deep Steeve/brain

== ERROR: stack overflow,  reason: brain too deep

it's not just looks. deep semantics that are used to make the GUI 
function properly relies on functional styles rather than appearance 
of styles. if you have a red button, the GUI won't know of its importance. 
but if you have an OK-BUTTON, you can tell how important it is, when 
it should be focused and what you are allowed to do with it. automating 
this can cut off hundreds of hours of development and testing time, 
because you don't have to pay attention to those details. the UI 
system does that for you.

eg.

condition: either boolean [ button ] [ no-ope ]

view compose/deep [
	button
	(condition)	
	button
]

view compose/deep [
	button
	(IF condition [button])	
	button
]

>> condition: false
== false
>> probe compose/deep [ button (if condition [button]) button ]
[button none button]
== [button none button]

>> compose/deep [ button (either false [[button]] [()]) button ]
== [button button]

In fact why don't we consider using parens to switch out of the layout 
dialect instead of making us use compose'deep

so either there is a compose/deep somewhere .. or there is a switch 
to the do dialect occuring

box clipping of gobs is making them harder to use than they should 
for general graphics use when gobs are nested into panes. 

it would be nice to be able to support a clip? parameter.


for example, it would be nice to be able to use 0x0 as the origin 
in which to draw (so that negative offset values be used in the draw 
block), but we can't unless we always add a transform to the draw, 
which has to managed along with the size at any change in size.


go three pane deep, and we have to manage all the hierarchy all the 
time its pretty complicated for nothing.  


pane grouping should allow them to be used, just for transform, not 
only for visibility.

btw - in DOS era, we had one concept in UI, although it regarded 
only the grid - each user could save his/her grid setup. Now as reordering 
of tabs is possible, it would be maybe nice to allow to save UI set-up. 
But I did not think about such concept in deep, so not sure how it 
would eventually complicate the matter ...

Why following works:

child: make-face 'window reduce/no-set [content: lay]

while following does not?

child: make-face 'window compose/deep [content: [(lay)]]

lay: [button "OK"]
child: make-face 'window compose/deep [content: (lay)]
view child

you need to use either the one you wrote:

child: make-face 'window compose/deep [content: [(lay)]]

,or the one I wrote

Petr, as said hunndred times... we are first drilling deep to get 
the concepts right. Than we are boing broad by priority. This means: 
Focus on few (2-3) styles

Cyphre - let's be realistic - I am the only one, because in fact 
I am most probably the only one, who is investigating GUI in such 
a deep manner, if not at all. This is imo a result of bad RT's treatment 
of R3, which is bringing REBOL into isolation even further more, 
making less and less ppl interested with almost zero RT's action 
... and that's the reality ...

Wrong, reasons: 

- those values clearly *are* options the user specifies

- the fact that some options may be inlined (i.e. the name may be 
used in another context) does not change that in any way

- what is "deep" about saying you don't like a name (in an arguable 
case) is beyond my understanding

- renaming to "facets" would not help anybody including Pekr as he 
surely knows

Pekr, Kaj :

checking, and modifying the code. In some tens of minutes,I will 
put a new version, with the latest r3-gui.r3 version. Later (in some 
days) I will go more deep in the non working tests.
Pekr, thank you for the doc patch : it works

I have not intention right now to burry deep into CSS, as I think 
I know enough to understand consequences. Your "you are wrong here" 
does not work for me :-) Wrong in what aspect? I still think, that 
I do understand how you style html pages :-)

Still into deep rewrites.

FUNC in R3 does a COPY/deep of its spec and code blocks, so it's 
safe to use here.

FUNC does a COPY/deep of its spec and code block, for safety and 
recursion-safe use within functions (see the source of COLLECT for 
an example of this). However, the internal code uses a non-copying 
version to lower overhead. That non-copying version is assigned to 
FUNCO as the last thing, and the copying version assigned to FUNC. 
FUNCO is left defined for power users who can asses the safety of 
not copying their function specs and bodies.

rebol[
	file: %carte-db-joueur.r
]


db-joueur: make object! [
	table: 't_joueurs
	oo: make joueur []
	
	
	list: func[
		o[object!]
		/local
		fields-in-file
		where
		test-nom
		test-prenom
	][
		fields-in-file: select my-db/tables :table
		where: copy []

  if all[(not o/id = 0) (not none? o/id) (not empty? o/id)]  [append 
  where compose [id = (o/id)]]

  if all[(not none? o/nom) (not empty? o/nom)] [append where compose 
  [find nom (o/nom)]]

  if all[(not none? o/prenom) (not empty? o/prenom)] [append where 
  compose [find prenom (o/prenom)]]

   return self/find-where fields-in-file compose/deep [all [(where)]]
	]
	
	find-obj: func[
		o[object!]
		/local
		fields-in-file
		where
	][
		fields-in-file: select my-db/tables :table
		obj: none
		where: copy []
		
		foreach field fields-in-file [
			if not none? o/:field [
				append where compose/deep [(field) = (o/:field)]
			]
		]

  return self/find-where fields-in-file compose/deep [all [(where)]]
	]
	
	find-where: func [
		fields-in-file [block!]
		where[block!]
		/local
		return-list
		data
		obj
	][
		return-list: copy []
		data: copy []	
		obj: none
		either not empty? where [
			data: (db-select/where * :table :where)
		][
			data: (db-select * :table )
		]
		do compose/deep [
			foreach [(fields-in-file)]  [(data)] [
				obj: make oo []
				set obj reduce [(fields-in-file)]
				append return-list obj
			]
		]
		return return-list

	]
	
	insert: func[
		o[object!]
	][
		db-insert :table compose [next (skip get o 1)]
	]
	
	update: func[
		o[object!]
	][
		do compose/deep [db-update/where (table) 
			[(skip select my-db/tables :table 1)]
			[(skip get o 1)]
			compose[id = (o/id)]
		]
	]
	
	delete: func[
		o[object!]
	][
		db-delete/where :table compose[id = (o/id)]
	]

	commit: func[
	][
		db-commit :table
	]
]

Regarding Robert's question about not erroring out when accessing 
non-existent object words, I tend to agree with the current implementation, 
but not necessarily Brian's rationale that errors are our friends. 
There are a number of places where REBOL could raise an error, but 
doesn't, and more have been added in R3. It's a balancing act, and 
depends on what we think most people will use, and will lead to common 
cases being clearer and more correct. 


I think it would be great to collect language design questions, and 
have Carl answer them. It would be good for REBOL. Some answers may 
be "we tossed a coin", and that's OK too, but many will have deep 
or important answers that may just appear as caprice from a user's 
perspective.

here's mine:

flatten: funco [data [block!] /deep][
    deep: if deep [[:data]]
    parse data [
        while [to block! data: change skip data/1 deep]
    ] 
    head data
]
>>flatten [[[1]] [[2]][[3]]]
== [[1] [2] [3]]
>>flatten/deep [[[1]] [[2]][[3]]]
==[1 2 3]

how about this, is it intended?
>> f:  func [self] [self]
** Script error: duplicate variable specified: self
** Where: make func
** Near: make function! copy/deep reduce [spec body]

I think this is all under-engineered - not finished in design. There 
was never any resolution posted to the topic. And the topic is deep. 
It reaches even continuous reading and parsing (streaming) and codecs 
...

>> f: func [/local self] []
** Script error: duplicate variable specified: self
** Where: make func
** Near: make function! copy/deep reduce [spec body]

Pekr, that's almost it, but not quite:

- All functions are a wrapper around a spec and a body, though the 
body of natives is internal.

- You will be able to make a new function derived from an old one, 
with a new spec, body or both, or just the same.

- When the spec isn't changed in the derived function, it will likely 
get a copy of the old spec, not the original.

- When you make a new REBOL function without changing the body, the 
new function will have a deep copy of the body, not the original.

- When you make a new native function (action!, native!, command!, 
maybe op!) it will call the same code, not a copy.


We'll have to see what changes we can safely make to specs without 
breaking functions. Right now we know we can change doc strings and 
typespecs, but we'll have to see if we can change argument ordering, 
naming and number. I expect that more changes will be possible with 
REBOL functions than there are with natives, due to the new function 
getting and rebinding its own copy of the code block. And natives 
might need some more internal type screening in order for this to 
not be a problem.

When you make a new REBOL function without changing the body, the 
new function will have a deep copy of the body, not the original.
 - why the copy?

Gobs are unique, and copying one can't copy its subgobs. In theory, 
COPY/deep gob! could work, or COPY of a gob! with no subgobs, but 
COPY gob! with subgobs would need to trigger an error. Instead of 
doing that (since COPY doesn't otherwise trigger an error), it was 
decided to ger rid of COPY gob! altogether, and use MAKE gob! instead.

I'd prefer to have copy work on gobs and yes, enforcing /deep since 
it can't be done any other way.


I can see situations where one would want to store gobs and duplicate 
them as bunches, especially when they are small bits and pieces strung 
together.

For one thing, gobs can't copy their data references even if you 
use COPY/deep, because gobs don't understand what is in those references, 
and because in almost all cases there are reference cycles in the 
GUI between the gob and the object referred to by the data. I can't 
imagine it ever being safe to copy gobs in a real GUI.

which usually means he is in deep thought.

... or in deep sleep :-)

unfortunately that error is caused somewhere deep within libr3, so 
i don't get any further than this :)

Originally I thought, that the FUNCT function was quite adventurous 
doing a deep search for set-words. But, after using it a couple of 
times, it really looks like it does what is useful most of the time.

yeah, he doesn't seem to grasp that there is just one function! type 
 ;-)

and there is that nice little line in funct :   collect-words/deep/set/ignore

which pretty much explains it all  :-)

This was used with small pieces of XML, rather than entire documents, 
but might be a starting point for you.


xml-get-field: func [input name /local xml-field= data other-name] 
[
	xml-field=: compose/deep [ 
		some [

   (rejoin ["<" name ">"]) copy data to (rejoin ["</" name ">"]) to 
   end
			| skip ;(to paren! [prin '.])
		]
	]
	either parse input xml-field= [data] [none]
]

R3 is currently undergoing open-heart surgery, with Carl deep in 
system and architecture mode... with all of the stuff fresh in his 
mind.


I think its the perfect time to overhaul the task! system and finally 
make a real architecture/API and identify,  solve,  or decide on 
the potential issues "hard issues".

is there a way to tell R3 to automatically show stack information 
when errors occur (and aren't trapped)?


python allows (on by default IIRC) this and its a MUCH more usefull 
error report.

for the same reason as for Rebol... many errors don't occur in user 
code, but in mezzanines, called by user code, sometimes several deep.


knowing why and where an error occurs is usually as usefull as what 
is the error  (and often, even more).

This is probably the least "cryptic" way how to be able to initialize 
functions:

func-with-init: func [
	init [block!] {initialization code}
	spec [block!] {
		Help string (opt) followed by arg words 
		(and opt type and string)
	}
    body [block!] "The body block of the function"
] [
	spec: copy/deep spec
	body: copy/deep body
	insert body compose/only [
		if init? (init)
		init?: false
	]
	body: use [init?] reduce [
		first [init?:] true
		body
	]
    make function! copy/deep reduce [spec body]
]


>> fr: func-with-init [initialized: now] [] [print ["this function 
was initialized:" initialized]]
>> fr
this function was initialized: 22-Sep-2010/9:36:22+2:00

no Brian is doing the module work, its just that the changes to how 
the contexts are now layed out provoke deep changes in how things 
are bound.


because that is a big part of the module system's job, it means Brian 
has to update a lot of the code.


also remember that Brian has been splitting up the module code into 
sub-functions, so all of that makes it simpler, and more re-usable.

one thing that continually amazes me is that meijeru is probably 
the most prolific R3 bug poster/tester ever,  yet we know virtually 
nothing of him... 

its very intriguing that this guy has such deep knowldege of R3 but 
doesn't actually seem to be actively participating in any public 
Rebol project or employment that I know of.


maybe even more importantly where it not for curecode we probably 
woudn't even really be aware of this seemingly really nice guy...

Thanks.....Looks like you and Brian have some deep dialog going around 
those issues.
Hope it all comes clear in the end :)

Of course his speed claims are relative. I added some reaction to 
show how to extend objects, but studying JS prototype documentation, 
I wonder if something like that would be possible to simulate using 
REBOL? I know that we can have sub-objects shared/referenced. But 
JS Prototype is not just that - it is not about classes. It is more 
about the ability to have linked objects, and when querying a value, 
it is being looked-up down the road:

obj/value 


If 'value is not found in the object, then JS looks down to obj/prototype/value. 
And 'prototype here can be referenced from different constructor. 
I think, that it is similar to find/deep, but with simple/single 
accessor.

Generally I remember two enhancement requests in REBOL:


- find/first - from the list of objects find first one matching the 
query

- find/deep - look-up in nested structures. Most probably blocks 
were meant, so not sure it would work for objects ...

Pekr, I don't know the deep details and I can't access the source 
(SVN trouble), but I can see one of the goals being that some parts 
are logically implemented in REBOL, because that makes them easy 
to maintain, rather than sifting through C code.

It seems that copy/deep doesn't work on map! Is it known problem?

My brother did it in the past, but sold the equipment. I really wonder, 
what are Carl's thoughts, as even my dog understands, that REBOL 
situation is in deep .... :-)

Because FUNC do copy/deep. hmm is this smart?

Sunanda, agreed, and also about it being clunky, particularly because 
USE has both COPY/deep and BIND/copy overhead in R3. ASSERT/type 
[local none!] is still the most efficient method.

It's possible to create infinitely deep series with this:

>> s: [a b c]
== [a b c]
>> insert/only tail s s
== []
>> s
== [a b c [...]]
>> s/4
== [a b c [...]]
>> s/4/4
== [a b c [...]]
>> s/4/4/4
== [a b c [...]]

and so on.

SFarber, it depends on what your goal is. If you want to have some 
plain fun with programming and create some handy tools, or go into 
discovery on how deep REBOL is, then REBOL is fine, even if R3 is 
not visibly moving right now. If you want to compare its momentum 
to, say, Python or Ruby, and look at the suite of libraries for them, 
then REBOL clearly loses out, because it is not as widespread.

it is actually the proper way even for safety

 - Why so? Once the function is made, security dictates that the accessibility 
 of its bound body should be limited. If you can get a bound body, 
 you can trace through the bindings to get access to any internal 
 code it references. That is why R3's BODY-OF does something like 
 an UNBIND/deep COPY/deep. If MAKE function! does a BIND rather than 
 a BIND/copy, that means that any extant references to the original 
 body block argument are a potential security hole unless they are 
 contained.

Yes, we've made other functions help work around the potential security 
weakness of MAKE function! - that's the tradeoff we made for efficiency. 
And as long as you either use COPY/deep generators like FUNC, or 
control the accessibility of your source, it's a really good tradeoff.

get-node and set-node are also from %mezz/trees.r ; most likely you 
don't want to mess around with %mezz/macros/trees.r , that is deep 
vodoo i use to make the html filter fast.

The discussion in bug#1625 is turning into a fairly deep explanation 
of the R3 script and module bbinding models, the meaning of FUNCT 
and why we have it, and the inherent limits of REBOL that were why 
we did things the way they are now. Take a look, it could be an eye-opener 
to anyone interested in this group.

unfortunately YouTube does not provide the possibility of deep linking 
into movies which are part of a playlist, so context of playlist 
gets lost

Nicolas, you can embed a deep link to the start of the Red presentation 
after 25 minutes in the film:

o: context [test: 123]
append h o
n: context [n2: context [h]]

Above is just a concept of what I want which is to create an object 
with an object that contains the object(s) held within h block. I've 
tried compose/deep binds and just about everything else I could think 
of.

The context of this is I have created objects which are held in a 
global block represented by h. I then have to  put these all together 
as one object. I just can't get rebol to do that. I always get a 
rather empty object.

And what about purchasing a faster computer ? 

(I'm in a deep shit right know, I don't understand what he's talking 
about)

one factor that makes me think this is deep, is because it doesn't 
occur until the main window has been opened.

That's deep even by native bug standards.

Here's a working version:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

Is there a trick / limit to just how deep one can create an object 
which itself has nested objects stored in a block? I have this xml 
string that I converted to a block via parse-xml but at about two 
levels in, it remains a block (make object!...)

Onetom, that error has been reported already and fixed in R2/Forward, 
but it hasn't made it into R2 yet. Here is the revised MAP-EACH:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

Looking at SPEC-OF, and another question pop up. Why isn't copy/deep 
the default for COPY? Wouldn't the world be much easier, if it was?

Geomol, using copy/deep by default would be extremely bad for speed 
and memory.   in most of the processing, you don't need to copy the 
deep content of a block, but the wrapper block itself, so you change 
the order or filter it.  


IIRC using copy/deep also causes cyclical references to break-up 
so using it by default would be disastrous.  


just look at how often we really need to use copy/deep compared to 
not and you'll see that the current behaviour is much more useful.

I wish compose/deep didn't copy/deep the whole block when it did 
its composing.  


I don't know how it is in R3, but in R2, to simply replace one value 
in tree, you have to copy the whole tree, which isn't very useful.

what is the fastest way to deep copy a large object?

Today's Moment of REBOL Zen:

>> s: "abc"
== "abc"
>> t: copy next s
== "bc"
>> index? t
== 1
>> b: []
== []
>> insert b next s
== []
>> index? b/1
== 2
>> p: copy/deep b
== ["bc"]
>> index? p/1
== 2


So copy/deep a block does not use copy on each member of the block 
in the normal sense of copy.

you have no recourse

 is a polite way of saying "you are out of luck". At least regular 
 programmers would be out of luck there - I'm sure someone like Ladislav 
 could come up with an arcane workaround, or you could give up on 
 RETURN and EXIT and use another escape function instead, like THROW. 
 But I assume that you know what I meant by "recourse", and want the 
 point explained.


Pardon me, that question needs some background info. The return models 
are being used to deal with a basic problem of functions catching 
RETURN and EXIT when you don't want them to. This is the case with 
many mezzanine control functions which take and execute a block of 
code. We have been putting requests for new mezzanine control functions 
on hold for quite a while because they can't currently be made to 
pass through RETURN and EXIT, but USE and COLLECT got through before 
we started that, and the restriction is lifted now.


Let's use USE to illustrate, ignoring for the moment that USE *can* 
be rewritten so it doesn't use an inner function.

use: func [
    "Defines words local to a block."
    vars [block! word!] "Local word(s) to the block"
    body [block!] "Block to evaluate"
][
    apply make closure! reduce [to block! vars copy/deep body] []
]


USE uses an inner function to create a binding for its words (the 
closure!). For the dynamic return we have now, the inner function 
catches returns from the body, but even if it didn't the USE function 
itself would catch those returns as well.


One proposal to solve this would be to switch to definitional return, 
which means that RETURN and EXIT would be redefined in the code block 
of a function to return directly to that function, not any intermediate 
function in the call chain. This would solve returns being caught 
by the USE function itself, because the body of code that contains 
the 'return or 'exit words is not physically in the code of the USE 
function, it is only referenced by word. However, that block of code 
is used by the inner function as its code block, so the inner function 
would redefine those words and catch the returns.


If your function uses inner functions like USE does, and can't be 
rewritten to not use them, and you are using definitional return 
without the option to turn it off, then the inner function will localize 
RETURN and EXIT every time.


As a caveat, I wrote that phrase before I came up with the workaround 
in the next section of using direct references to the RETURN and 
EXIT function values instead of referring to them by name, which 
avoids the rebinding issues because no words are involved. See the 
code in http://curecode.org/rebol3/ticket.rsp?id=637to see what 
that workaround makes your code look like.

ok, I've read the whole exceptions document and a few (very old!) 
tickets at least 3 times now.


I'll start by being honest and saying that some of this is going 
a bit deep into some details and I'm pretty sure that I'm not graping 
all implications.  The background for all the discussion hasn't "sinked 
in" yet, so its a bit hard to be totally conclusive about my evaluation 
thus far.


this being said... when I arrived at 5, i.e. "Definitional return 
only, with an option to not redefine RETURN and EXIT", it suddently 
starts making sense overall.  6. seems to be redundant and maybe 
even harmfull if we keep THROW dynamic.  This is scaled with CC#1744 
"fixed" and a wider use of THROW, encouraged, since it now allows 
custom escape/exception modeling by non guru-level Rebolers (and 
by guru I mean one of 3-4 rebolers on the earth... maybe not even 
including Carl ;-).


this means, that return does one thing, throw does another.  they 
become two completely different things, clear and conscice in all 
code.


the only real issue I have is that we seem to loose return in parse, 
 but if we keep throw dynamic, then that is moot, and we can just 
use THROW instead.  In fact, woudn't that be preferable, since its 
more accurate?  we are pre-empting the parse return and providing 
our own... which is what throw should be doing ... its more consistent 
overall.


so go ahead rip my arguments appart... it will only help me understand 
this completely.  :-)

I also think that Carl hesitates to give us lower-level constructs. 
 This has been the historic case, BUT, now that a lot of people are 
actively contributing and actually producing working concepts, ports, 
prototypes and stuff, Carl is slowly realizing how usefull it is 
for *him* to open up on the lower levels of REBOL.


the exception/return/throw discusission going on is a good example 
of this active participation of the community.  Obviously, not everyone 
is willing or able to participate, but in such deep discussions, 
there is rarelly a huge mass of people anyways.

Definitional (whatever) depends on a BIND to do its work, deep, usually 
BIND/copy. And that only works on words that are physically in the 
blocks that you bind, or in blocks that are nested in those blocks, 
etc. Another block that is outside the block you are binding and 
referred to by name won't be bound. That is the limit of the definitional 
approach.

The only difference would be to replace the (block) by (copy/deep 
block)

Right. COPY/deep is expensive for large code blocks, worse than BIND/copy 
(depending on the code). Copy overhead is a big deal.

Bind/copy may be inherent, but my not was a reaction to: "COPY/deep 
is expensive for large code blocks, worse than BIND/copy" - which 
may not be desired

Also, I adjusted the implementation of the definitional Catch/Throw 
pair in R2-like variant to:


- use FUNC instead of MAKE FUNCTION! to have the body (deep) copied
- unset 'throw for localization purposes