World: r3wp

Another function is the math EXP function. It just raises the number 
e to some power (the argument). A language like C (and probably most 
others languages) has this function (in the math library though). 
Probably to make code faster, but it can easily be defined as a REBOL 
function, right?

There are some rounding problems though, so it maybe can't be made 
easily, but probably using a trick.

>> exp 1
== 2.71828182845905
>> myexp: func [v] [2.71828182845905 ** v]
>> myexp 32
== 78962960182685.1
>> exp 32
== 78962960182680.6

So we might need more digits for e.

you know, I was half joking when I suggested this group... :-)

:) well, it's a good group for this, as Doc would consider these 
things at some point.

I just woudn't want it to take over the topical discussions related 
to actual Red implementation and use.

>> myexp: func [v] [2.7182818284590451 ** v]
>> myexp 32
== 78962960182680.6
>> exp 32
== 78962960182680.6

With 2 extra digits, it seems to work.

With e defined, the hyperbolic cos, sin, tan, etc. are easy (REBOL 
doesn't have these), and maybe also normal cos, sin, tan!? At least 
for complex numbers, but not so sure about reals. Maybe a better 
mathematician can tell us that? Ladislav?

John, in a real REBOL-like language + is implemented using ADD; all 
operators redirect to their associated functions. You could do a 
similar trick with a compiled REBOL-like language like Red. This 
brings up another question though: Will Red implement operators in 
a fixed-predefined-set way like R2, or in a user-defineable way like 
R3? I hope the latter, though the former would make sense for Red/System, 
at least in the pre-Red stage of its development.

Are complex numbers considered in Red?

User-defined operators are really nice, I think. Being able to write 
things like:

remove 42 from [1 2 3 42 177 280]

where FROM is just a simple FIND.

but as an operator.

that is really nice geomol

For now in R3 there are some restrictions about the kind of functions 
you can make an operator from - number of arguments and such. It 
is planned to eventually relax one of the restrictions, and allow 
function!, closure! and command! functions to be used. However, even 
in Red there will likely need to be a fixed format to the arguments 
of such a function: 2 args with no refinements, the first arg corresponding 
to the left side and the second arg corresponding to the right.

To make a FROM op you would need to make a FROM~ wrapper function 
around FIND; you wouldn't be able to make an op from FIND directly.

there could be various forms to the ops.  there can be a way to tell 
the op building process to be unary binary or ternary.

Yeah, operators with only 2 arguments sounds like a good idea. More 
and it fastly become too complex leading to confusion.

f

fastly
 :-D Think "quickly"

brian, can we already build the FROM as an op in R3?  I've tried 
using the to-op and I can never get it to work.

(though we should go back to REBOL3! group)

Maybe NOT can be defined as a function this way?


not: func [value][either none = :value or (false = :value) [true][false]]

Will Red implement operators in a fixed-predefined-set way like R2, 
or in a user-defineable way like R3?

 Op! will be user-defined as they were in R-sharp interpreter. Here's 
 a short extract of R-sharp's boot script:

+:  make op! :add
-:  make op! :subtract
*:  make op! :multiply
/:  make op! :divide
=:  make op! :equal?
<>: make op! :not-equal?

This would be safer to do in Red than it currently is in R3 because 
the compiler can perform all of the evaluation safety checks as part 
of its type checking, with no runtime overhead.

Exactly, safer and cheaper to do with a compiler.

If C doesn't allow struct parameters and return values, only struct 
references or pointers

C allows struct values as parameters and return value.

(They are often frowned upon in public API usage due to portability 
concerns, though.)

Are there size limits to these parameters and return values?

~size of the stack, I'd guess

yep

no size limits, but it's obviously a lot easier to blow the stack 
if you pass around lots of large structs as values

Even for return types? Are they just left on the top of the stack?

that depends :)

as i said, it's a portability mess

small objects are sometimes passed in registers

i.e. if your struct fits in two machine words, some (x86) compilers 
use eax and edx to return it

other compilers rewrite the function to take an additional parameter 
with a pointer to storage used for returning the struct

(this pointer is then sometimes passed via a register, others pass 
it via the stack)

Would that behavior be standardized for a particular calling convention 
and ABI? For instance, that seems like the kind of thing that would 
have been standardized by stdcall or fastcall, but maybe not for 
cdecl or pascal.

afair it's a mess in all of them

for x86

Sorry for all the questions - I haven't needed to write a C compiler 
yet. All the languages I've written compilers for or hand-compiled 
were really specific about this kind of thing.

on amd64, this is mostly fixed

i have a handy reference by agner fog for intel platforms somewhere

If you find the link, please post it :)

but the gist of it: x86 is fscked, x86_64 is much better :)

here we are: http://agner.org/optimize/calling_conventions.pdf

table 6 in section 7.1 on page 19 sums up the mess that is struct 
passing :)

but beware, that is for c++

but we can say, in practice,  that if Red doesn't support struct 
passed as value (or return)... no one is really going to notice. 
  I have never actually seen code in the real-world which does this... 
simply because its very clumsy to do so.