World: r3wp

Carl requested the modularization. And I definitely wanted to do 
it because the whole module and script system didn't pass the hit-by-a-bus 
requirement.

hehe... I agree  ;-)

I can't help but wonder if we'll ever get maps that are meant to 
be used like maps ...

actually the cultprit is the path walking here... but I agree that 
using them as objects within path notation is strange.

brianH can you tell me *why* path notation evaluates map lookups?

(I have no gripe with the path notation. It's the old strict-equal? 
issue the above was hinting at.)

brianH  " increased language consistency" if this where true, then 
we couldn't store object in blocks without evaluating them by default 
either. 


IMHO maps are just hash tables, just like a block.... storage, not 
vector jump tables.   but that might just me my skewed view of the 
world.

oops... sorry my last statement was a bit messed up... ignore the 
first line...

Well, it sure _is_ more consistent to always have paths which ultimately 
refer to a function! make the function an "active" value.

Wether that consistency is desirable or worth anything is on another 
page.

But it generally simplifies things if you don't have to re-define 
the semantics of all path variations.

anyways, we do have get paths now... so I guess I'll just shut up 
and stop stirring air  ;-)

Yeah, and that illustrates the consistency argument: if paths with 
a map! as underlying would be redefined to behave like get-paths 
per default, what should get-paths on maps do :) ?

shave my neighbor's unclean dog?  ;-P

I'm more for making coffee, but that's not too bad an idea either 
:)

Hi, I corrected http://www.fm.tul.cz/~ladislav/rebol/evaluate.r(I 
omitted a USE-RULE call for the last rule in the script), and renamed 
the accumulator 'a in accordance with industry standards.


Also, I added an efficiency note related to R3 protection disallowing 
us to use a simple binding method to create the USE-RULEs during 
function initialization (creation) instead of creating the USE-RULEs 
every time the respective function is called, which is inefficient.


I wonder, whether we should consider a way how to allow the creator 
of the function to perform some additional initialization during 
function creation.

As I demonstrated in the %use-rule.r script, such an initialization 
is possible using a method to circumvent the protection R3 uses, 
but it looks neither simple, nor very efficient.

Some bugfixing for A108 - http://www.rebol.com/r3/changes.html

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

The initialization has to occur in the function body, unfortunately, 
otherwise the R3 protection does not allow BIND to be used, which, 
on the other hand, means, that the IF call is done every time the 
function is called, which means additional overhead

But, anyway, this solution looks less "cryptic" than the one used 
in the %use-rule.r script, I guess

Another disadvantage is, that for this version to work, the 'init? 
variable must not be an argument (local variable) of the new function.

http://www.fm.tul.cz/~ladislav/rebol/func-with-init.r

A108 now uses  #  to represent none... neat!

Thanks for doing the func-with-init research Ladislav. While I think 
we sometimes focus too much on optimization, I can see this as being 
important in the big picture for writing function generators that 
produce efficient results.

This version is not as cryptic, even though it's longer. I can understand 
it. :-)

http://www.rebol.com/article/0487.html

Function splitting.

bleeeah :-) REBOL as a messaging language has networking protocols 
being an optional package = no standard functionality over the REBOL 
installations. Great, what's removed by default next?

Pekr, network protocols are still there and bundled within the binary.

So they still are "standard functionality over the REBOL installations".

It's just that you'll hvae to explicitly import them, if you need 
them.

Let's use DECODE-CGI as a simple example: currently in R2, you fire 
up R2 and can use decode-cgi in your code straight away.

Currently in R3, it's not there at all.

In the future in R3, the code itself will be bundled with R3, but 
if you fire up R3 and type decode-cgi, it won't be available straight 
away. You'll have to explicitly import the CGI functions with import 
'cgi first.

do you use rebol without networking or db protocols? what for?

Yes. Many different scenarios. I have never used REBOL's ftp protocol, 
for example.

And obviously there are many REBOL scripts which will never need 
the CGI stuff :)

Pekr, I believe this is not just for distribution purposes, but for 
allowing R3 to start up faster in certain cases, not having to initialize 
various protocols, etc.

And to reduce clutter in the "global" default namespace.

The question is what tradeoffs are best? I have to say, even with 
Base available, I like having everything just work out of the box. 
How much does each exclusion save us? This is a tough call. Of course 
I want things lean and mean, but I also don't want every script I 
write to have 5 or 10 lines of import statements for what we've come 
to expect as standard functionality.


Do we have any kind of cross reference or dependency list? That is, 
do we know exactly what we're talking about?

Gregg, same response to you: nothing will be excluded. Just not imported 
by default.

And you can do imports in the header, or on a single line.

and the plus package is on by default, unless you switch it off on 
the command-line.  which is a good idea IMO.

IMPORT with a block! as argument does the same as the NEEDS block 
in a header.

Right, what I don't want is to have to explicitly import "basic functionality" 
in every script. The question is what is basic? And while we can 
certainly do it in a single header line, that's far from the same 
as having it "just work". 


I just want to make sure we're saving enough to make it worthwhile. 
You know how I hate premature optimization. ;-)

That's precisely the point: what one considers "basic" functionality 
varies widely :)

I think the point of the public release of this effort is to collect 
what you want (or not) as default.

And some simple modularisation helps everyone, in the end.

Right, so where is our list of options and dependencies?

Heh, _compiling_ that list of options and dependency is part of the 
work in progress, I think :)