World: r3wp

That is what  I like about the name. A programmer will understand 
the difference. REBOL is made for programmers, not laymen. We finally 
disabused ourselves of that delusion.

When do you use e when not doing exponents? Not familiar with e's 
use - I took calculus in 1987 and haven't used most of it since.

yes, but in the above case both "real" and "float" are actually of 
the "same information value" for an expert - not knowing from the 
name neither how many bits they use, nor what is the base (2 or 10)

re E: Rebol has LOG-E, so it would be natural to have E defined, 
the problem I see is, that the name is "too short", so Carl wanted 
to leave it for "common use"

Ah, but "float" is a keyword for programmers that implies binary 
floating-point numbers (usually IEEE754), while "real" is a keyword 
for what floating point numbers (binary or decimal) *appproximate*. 
You know, the real world. The "real" pi doesn't have a finite binary 
representation. That distinction is why I like "float" instead. All 
moot now though - we are stuck with decimal!.

We could call integers for Integral, like Python have numbers.Integral
(just kiddin)
I like integer! and real!
(I may change my mind.)

Should the hyperbolic math functions be part of REBOL? Like the C 
functions cosh, sinh, tanh. Many languages have them (I've checked 
Lua, Python and Ruby).

Pekr as for HTTPS protocol I agree with the other people here. Lets 
some external developer do the work once the basis is complete.

I was very amazed to read that even Gabriele sometime gets no answers 
from Carl. He is one of the closest developers to RT !

However, if we could summarize 2009, it has been a nice year for 
REBOL. Many things have evolved and I have not seen the development 
blocked for more than a week. I don't know how many people are still 
at RT but I suppose the number is quite low and I think we must congrat 
with Carl.

If we think about the needing for money and time a company and a 
family needs (talking about Carl's Family and RT) I am really suprised 
to see how much work has been spent over REBOL. Sometime I even ask 
myself  how it could be possible ? Has Carl some hidden treasure 
? Has he found a way to split himself so we have 2 Carl and not one 
? :-)

I asked Carl to react on reboltutorial article and to add old R3 
architecture doc I remember from the past. It is on R3 rebol.com 
page now ....

ppl were constantly confusing and merging R3 product with R2 marketing, 
although the model was explained many times ....

I am glad the doc is back ...

Changes to high resolution time in R3 - http://www.rebol.net/r3blogs/0293.html

Is there a way that I can get the number of parameters of a function 
in R3? 
So I can do this:

>> num-of-parameters :print
== 1
>> num-of-parameters :now
== 2

should be: >> num-of-parameters :now
== 0

num-of-parameters: funct [ f [ any-function! ] ] [
    clear find spec: spec-of :f /local

    remove-each element spec [ any [ string? element block? element ] 
    ] 
    length? spec
]

Important - Finalizing read and write - http://www.rebol.net/r3blogs/0294.html

Jerry - you can use words-of instead of spec-of. It doesn't return 
the comments.


>> a: func [b "comment" c "comment"  /local d] []                
        
 
>> b: func [c d e f /local z] []

 >> n-o-p: func [f] [length? copy/part spec: words-of :f find spec 
 /local]
 
>> n-o-p :a
 
== 2


>> n-o-p :b
 
== 4


Sory for the cryptic code. I had to keep it to a single line in the 
R3 console.

The code above doesn't handle 0 parameters though :-(

... and more importantly it doesn't handle refinements either.


What would you expect num-of-parameters to return for the following 
function:

a: func [b c /d e /f g /local x y z]

clear find spec: spec-of :f /local     ... can move the refinements 
part

Here is a version using parse:


>> n-o-p: func [f] [ct: 0 parse words-of f [some [word! (++ ct) | 
refinement! thru end]] ct]
 >> n-o-p :now
 == 0


>> a: func [b c /local e] []
>> n-o-p :a
 == 2
>> x: func [b c /d e /f g /local x y z] [
 
>> n-o-p :x                                

== 2

A version without parse:

>> npars: func [f /local w] [
	w: words-of :f
	length? copy/part w any [find w refinement! tail w]
]
>> npars :print
== 1
>> npars :now
== 0
>> npars :insert
== 2

Some thought of naming. How should such a function be named the REBOL 
way?

number-of-parameters seems a bit long. I sometimes write functions, 
that return the number-of something. I come to think of # as being 
number-of, but # in the start mean an issue! datatype. What about 
allowing # in the end of words? Like:

parameters#: func [ ....

Or is that too ugly?

A bit like we have ? in the end of many words: length? tail? none? 
...

Maybe not pluralis, but just
parameter#: func [ ...

num-args, num-of-args ?

args-of

Remember that there is nothing special about the /local refinement 
or the words that follow it. All /local is is an option that you 
aren't using, and in that is no different than any other option you 
aren't using. In order to determine the number of args that a function 
takes, you need to specify which options you will be using in the 
call, perhaps by providing a path! instead of a function reference. 
Otherwise, just use WORDS-OF.

Thanks you guys, very helpful.

John's non-parse version looks to be the fastest on 10,000 iterations 
with :print, :now and :insert :

Jerry's original took 0:00:00.346343

John's version took   0:00:00.06549

Parse version took    0:00:00.129942

Try this one (words-of already copies, no need to again):
npars: func [f [any-function!] /local w] [
	length? also w: words-of :f clear find w refinement!
]

Version without also:
npars: func [f [any-function!] /local w] [
	clear find w: words-of :f refinement!
	length? w
]

CLEAR and REMOVE of none just return none and don't complain. This 
allows chaining without needing conditional code.

Both very fast - no real difference between them:

Jerry's original took             0:00:00.355178

John's version took             0:00:00.061354

Parse version took              0:00:00.129759

Brian's 1st version took      0:00:00.056886
Brian's 2nd version too k    0:00:00.051447

The type test in the argument list might be taking a little time. 
Try John's with the type spec. I'm curious to see what the difference 
is.

I mean the [any-function!] part.

Is struct! working in actual version? If so some example would be 
handy!

To Brian I've read your description between FUNC and FUNCT in DevChat. 
Never seen such summarizing description anywhere, but I think it 
is very usefull not for beginners only but for everybody not so hawkeyed 
as gurus. This should be mentioned in docs, or even better short 
lectures shall be written about such "deep lake" details (to reproduce 
Carls definition)

Adding the type spec didn't make any significant difference.

I think that struct! and routine! are there left-overs from R2, and 
will be removed, as we are not going to get DLL interface, I wonder 
what those two datatypes would be good for. Maybe struct! might be 
usefull, if made more powerfull, dunno. Our interface is now Extensions.

Yes Pekr and when you want to write Extension as generalDLL loader 
can you use a block! paramerer instead of struct, or better how to 
transform a block given as parameter of extension to struct needed 
as parameter of underlaying DLL.

Good to know, Peter, thanks. Type checking was sped up in R3 through 
typesets.

The R2-style struct! and routine! types are not working in R3 and 
are likely to be removed. The struct! type might be replaced with 
a new, improved, incompatible struct! type. The routine! type has 
already been replaced with a new, improved, incompatible command! 
type.

You are right that documentation is an ongoing problem. The design 
has been changing a lot during the alpha phase, but the behavior 
of FUNC and FUNCT are unlikely to change, so they could be documented.

I added a ticket to curecode about the math performance issue: Ticket 
#0001338

Have you tested with prefix form math? The implementation of op! 
has changed, and the new implementation would probably be slower 
(at a guess) but is more flexible. Please test with prefix math so 
we can categorize the ticket properly.

If functions like ADD and SUBTRACT are slower, this is an issue. 
If it is just ops like + and - then it is a side effect of user-defined 
op!.