World: r3wp

Many new funcs play with the supplied series which is great!

Here's the R2-Forward version:

first+: funco [
	{Return FIRST of series, and increment the series index.}
	[catch]

 'word [word! paren!] "Word must be a series."  ; paren! added for 
 R2
][

 ; Workaround for R3 change in lit-word! parameters with paren! arguments
	if paren? :word [set/any 'word do :word] 
	throw-on-error [also pick get word 1 set word next get word]
]

what is funco? I read its help, but don't understand. So normal function 
creation in R3 creates copy of body, whereas funco shares it?

funco remains me pulco citron (pulco citrus) a beverage

there starts to be too many function related functions: function, 
func, funct, funco ....

Right. FUNCO is basically like R2's FUNC - only sa to use under certain 
circumstances.

Pekr, you have the sources of func and funco in R3

But without the throw-on-error stuff.. Just use it for functions 
with correct syntax.

funco: make function! [
	"Defines a function, but does not copy spec or body."

 spec [block!] "Help string (opt) followed by arg words (and opt type 
 and string)"
	body [block!] "The body block of the function"

][ ; For functions known to have no syntax errors or recursive issues.
	make function! spec body
]

just weird naming which makes no sense. REBOL always tried to name 
things full-name, not some weird abbreviations ... this is not the 
case with function related functions ...

That's the R2 version.

would it be much slower to have just one with refinements?

surely

It's short for func-original. It's the function used to define many 
mezzanine functions in R3. Fast, no error checking.

Pekr, the answer to your question is yes, it would be *much* slower 
to have one with refinements.

That's why the only function creation function with a refinement 
is FUNCT - since it does so much work anyways that the refinement 
overhead is much lower in comparison to the rest of the code.

Then we need new format supported in native code - having named sections, 
which would be just a jump point for refinements: body: [copy [this 
is copy code] nocopy [this is nocopy code]] :-)

We have that: EITHER.

The problem is that what you suggest isn't any faster than EITHER 
or PICK.

... or switch or case ....

Yup :)

R3 alpha 54 released...... Two days after A53, and 32 curecode issues 
addressed.
That's fast work!

http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.54_14-May-2009

Not in the Mac ghetto  :-(:

>> upgrade
Checking for updates..
.

R3 current version: 2.100.51.2.5
 
It was released on: 6-May-2009/0:42:42 



Your version is current.

OK - no problem to ping Carl about it, no? I think he just did not 
generate it yet ...

Is this our Meijeru? :-) http://users.telenet.be/rwmeijer/

same name as in chat

yes, although no mention of REBOL on his programming subsite - http://users.telenet.be/rwmeijer/proglang/


btw - I found out he was announcing complete DOM implementation for 
REBOL? Has anyone actually seen anything like that? 
http://www.mail-archive.com/[rebol-bounce-:-rebol-:-com]/msg03548.html

I got a copy but it was not useful for me.

I don't think it is.  Didn't he live in the States?  The link provided 
indicates he is living in Belgium.

the guy above is living in belgium.

He is slightly sloppy with his english, in a way that made me think 
it is not his first language.

Everyone who is interested in the typeset debate, look here: http://curecode.org/rebol3/ticket.rsp?id=820

The question is whether binary! should be part of the any-string! 
typeset in R3. Since the Unicode conversion, binaries are arguably 
*not* strings anymore. Even if they support the same operations, 
all of the other string types contain characters, while the binary! 
type contains unsigned 1-byte integers (which characters are not 
in R3). What do you think?

Couldn't the same be said about the image?

Image is not in any-string! either. The binary! type would remain 
in series!.

continuing discussion in I'm new group...


brian: no R3 chat account yet... its basically that I'm keeping my 
energy.  I really would love to participate more in R3 but since 
most of what I do is commercial (REBOL), time invested in R3 is severely 
lost in the short to medium term.


but I think its now progressed enough that I really should participate 
more.  


I think I have a lot of insight to bring to the table since I'm one 
of those few developpers who has been using REBOL commercially for 
just about ever, I've been using a module clone for the last 7-8 
years,  built 4 complete view engines (even ported glayout to python 
;-),  implemented some of the largest apps (code wise), and have 
several dozen REBOL APIs under my belt.

I am reviewing the module system now (well, not right now since I 
am working). We have tried to balance simplicity and security, but 
I think the way we did that balance is to have two extremes which 
you can choose between with one refinement. I'm checking whether 
the simplicity extreme is too insecure, and whether the security 
extreme is too difficult to use.

The reason I am checking this now is because it is time to backport 
the module system to R2. The code is pretty easy (and mostly written) 
- the design issues are not. Since you've written a module system, 
your input may be valuable.

There will be changes to the R2 version of the module system due 
to the global context, but even that can be balanced.

this can be a big discussion... want to do so privately?

cause all I've read of the R3 engine, slim already handles a part 
from actual enforcing of the privacy.

it acutally does a lot more.

Yeah, let's not dump the details on everyone until we have some common 
ground :)

my input can be on what I did and didn't end up using afte 7 years... 
some features sound great on paper, but then don't really get you 
more productive and some features I've never used myself.

It's funny to see Carl wondering why there is not more requests related 
to the use of external libraries in R3.
Not so funny in fact.

If that feature, had not been discarded in R3, perhaps there would 
be more tries and more requests.

Not discarded, scheduled for a redesign. R2's FFI is really bad.

But it worked, Better to have something bad working instead of nothing 
at all

i can't do test about something vanished

Alpha. And the new model won't be compatible, though there is a proposal 
to make a plgin that implements a variant of the R2 FFI.

But Steeve is right - I had to correct Carl - the motives were quite 
different: some few weeks ago, he said that we should write it down. 
Once done, he said he tried to design plug-in interface, and got 
some issues with dynamic code like draw. So he worked on another 
proposition. I asked for more info, but he said he will release it 
later, because it had wider consequences ...