World: r4wp

Is http://www.red-lang.org/p/roadmap.htmlcurrent? You've been making 
so much progress, I'm guessing it's a little out of date.

Why default red's functions refinements value is false?

To avoid having to use to-logic when using refinements to pick a 
value in a series. For example:

In REBOL:
    foo: func [/only][pick [1 2] only]
    foo

    ** Script Error: pick expected index argument of type: number logic 
    pair
    ** Near: pick [1 2] ref

In Red: it should return 2.

Note that PICK taking a logic! value is not yet implemented, it will 
be added in the next days.

This is a code pattern I use often, but always find it annoying to 
have to add a to-logic call each time in front of refinements.

Gregg: It will need to be updated a bit, right

Thanks for supporting Red, Gregg! The others, too

Great Doc !

Funny, I usually just reverse the order of the PICK elements and 
use NOT.

Are only the refinements FALSE, or also extra arguments?

Unused refinements only. Extra arguments are set to none.

OK, that sounds useful

It is also more consistent, as used refinements are set to TRUE.

Just specifiying a return type adds 68 bytes to a function. Why is 
that?

(In Red)

It shouldn't have any effect on the generated code size. Can you 
send me the function?

It's the Fibonacci function in the C library binding. I checked in 
a Red version. If you add return: to that it becomes 68 bytes bigger

Does the function becomes bigger or the whole binary?

The binary. The function would be hard to estimate

Then, that's normal, the added size is for dynamically creating the 
extra literals you've added to the spec block. Remember that the 
source code of your function is built-in the final binary, so you 
can use reflection and soon, rebuid the function dynamically at runtime.

Also, you won't find the source code of block literals in text format 
if you scan the binary, because they are stored as code and not data. 
That is the only way currently they can be stored in compiled binaries. 
Storing them as text would need a way to load them and then compile 
them at runtime (it will be possible in the future, but not right 
now).


Anyway, the probably best way to store all those series literals 
is to allow the use of a redbin format. We will have that too at 
some point.

Ah, thanks

New features of the day: 
- SWITCH implemented (/default refinement supported)
- CASE implemented (/all refinement supported)

- FIND and SELECT extended to handle datatype values matching. Example:

    find ["hello" 2 red] integer!
    == [2 red]

Forgot also to mention that PICK and POKE now accept logic! value 
as index.

Re. Hex, how about underscore? Fairly clear and not too dissimilar 
to 0x2FAB notation.

0_ffccbbee 2_11011011 16_2FAB

Red/System Question: In Struct A, there is a menber which points 
to struct B. In Struct B, there is a member which is a function pointer, 
whose parameter is a pointer to Struct A. ... How can I do this in 
Red/System. This is not a fiction case. I am studying SQLite surce 
code, struct sqlite3_file and struct sqlite3_io_methods are exactly 
like this.

This any help?

Red/System []

a!: alias struct! [
  a1  [integer!]

  a2  [integer!]            ;; this is used to hold address of struct 
  b
  a3  [integer!]
]    

f!: alias function! [s [a!]]
f: func [s [a!]] [print [s/a1 lf]]

b!: alias struct! [
  b1 [f!]
]
  
a: declare a! 
b: declare b!


a/a1: 5
a/a2: as integer! b 
a/a3: 0
b/b1: as f! :f

foo: as f! b/b1           
foo a

Thanks, Peter

Jerry: if I understand correctly, what you want to achieve is:

    Red/System [ ]

    structA!: alias struct! [
        p [structB!]
    ]

    structB!: alias struct! [
        fun [function! [a [structA!]]]
    ]


As is, it won't compile in Red/System as structB! is not yet defined 
when defining structA! (and the compile is making a single pass only, 
so can't look ahead). 


The workaround is to define `p` as integer! and use type casting 
when accessing it.


Also note that if you reverse the order of definitions and start 
by defining structB!, you could use the same workaround for `a` argument 
type (define it as integer!, then apply type casting when appropriate).

I have added a new function type today: routine!. It allows to write 
a Red/System function in a Red program. The compiler will marshal 
(or type-cast) the arguments back and forth automatically.

Here is the Fibonacci example rewritten as a routine:

Red [ ]

fibonacci: routine [
    n          [integer!]
    return: [integer!]
][
    either n < 2 [
        n
    ][
        (fibonacci n - 1) + (fibonacci n - 2)
    ]
]


The function body is Red/System code, so it will run at full Red/System 
speed.


Integer! and logic! values are converted automatically, other Red 
datatypes are passed boxed but type-casted as Red/System counterparts 
(as defined in the Red runtime). Hint: floats will be converted automatically 
too.

So, passing and processing a block! series would look like this:

Red [ ]

add-one: routine [
    blk       [block!]
    return: [block!]
    /local value tail int
][
    value: HEAD(blk)
    tail: TAIL(blk)
	
    while [value < tail][
        if TYPE(value) = TYPE_INTEGER [
                int: as red-integer! value
                int/value: int/value + 1
        ]
        value: value + 1
    ]
    RETURN(blk)
]


I haven't yet released the code, it needs a bit more work, it should 
be ready by tomorrow.


The purpose of routine! datatype is to provide access to ultra-fast 
and low-level code for Red program in a simple way. The design is 
not yet fully set in stone, so suggestions and comments are welcome.

That's cool, it's something like rebcode.

How about something like having a block of Red/System code inside 
Red code?

System [...some R/S code...]

Endo, what you want is described in Section 17 in the Red/System 
Spec   http://static.red-lang.org/red-system-specs.html#section-17

Very cool Doc!

awesome.

In C, struct astruct { char c; int values[3]; }; How do I write this 
in Red/System? Thanks. It's the integer array which confuses me.

Thanks Jerry, shame on me :)

There are no arrays in this bootstrap version of Red/System. So you 
have to manage this with a pointer:

Red/System []

s: declare struct! [
  c  [byte!]
  i1 [integer!]
  i2 [integer!]
  i3 [integer!]
]

; intialise the structure
s/c: #"a"
s/i1: 1
s/i2: 2
s/i3: 3

;create a pointer and point it at the first integer
i: as integer! s

i: i + 4                          ;; set i to address of first integer
ip: as pointer! [integer!] i

;; add the integers
sum: 0
count: 3
until [
  sum: sum + ip/value
  ip: ip + 1
  count: count - 1
  count = 0
]

print ["The sum of the integers is " sum lf]

There is a probable issue with value alignment as explained in http://static.red-lang.org/red-system-specs.html#section-4.7

I'm not sure how to handle "packed" stucts in Red/System.

Also, the docs state that the value alignment may vary by processor 
so the line
	i:  i  + 4


may not be valid on all platforms (though I think it is safe with 
IA-32 and ARM).

That's cool, it's something like rebcode.

It has a broader range of usage and it's faster than rebcode.


How about something like having a block of Red/System code inside 
Red code?

System [...some R/S code...]


This is already implemented since a while in form of a Red compiler 
directive: #system [...]

Thanks. Peter. It's very helpful.

To have a tightly packed semi-array of dynamcic length, use allocate 
and free

Doc, thanks very much for routine!. It's brilliant and exactly what 
I need to make the bindings available from Red. However, #define 
not being context aware is still a blocker

There's not much that can be done currently for #define, you can 
use #enum instead to workaround it in such cases. 


Anyway, we will need to rethink the preprocessor in Red/System v2, 
and if possible, remove it. It has been added at the beginning of 
Red/System because Red was not yet there to provide a higher-level 
macro system. Now that Red is alive, we could start thinking of a 
better alternative to the current Red/System preprocessor.

That would be good; I still have mixed feelings about it

It would have to be something that can be processed by Red but still 
able to generate stand-alone Red/System

I would like to get rid of it, for many reasons. Firstly because 
it was not meant to be part of Red/System, but added later for practical 
needs, secondly because Red/System code could be built/composed more 
efficiently from Red.

In other words, we need some kind of Red wrapper (or maybe dialect) 
on top of Red/System to make it easier to construct programmatically.

Sounds right

I haven't had time yet to think about such replacement solution, 
so ideas are welcome.