World: r4wp

ah, thanks!

byte-ptr! is just a macro for [pointer! [byte!]] which is a bit more 
generic type than c-string!

yes, that works. Thanks very much!

another question :) how to get pointer to integer! ? as byte-ptr! 
converts the value and doesn't return address.

just use: as-integer <byte-ptr! variable>

Ah sorry, not what you asked for...

The get-word! syntax for integer! variables hasn't been implemented 
yet. So currently, the only way (AFAIR) is to wrap your integer! 
in a struct! (as you would do in REBOL).

I see, thanks.

There are several *-reference! types defined in my C library binding 
that do that:

integer-reference!:				alias struct! [value [integer!]]

Hi Doc,

   I have found the time to view the documentation of RED/System on 
   your site.

   Red/system brings the expressiveness of REBOL in a low level language.

   I see there is no object orientation capabilities into this language. 
   Is it planned ? Otherwise, as a programmer, why you dont find it 
   usefull ?

I think it is planned for Red as Red/System is a low level system 
language.

Endo, I know it will be available in Red as it will inherit many 
REBOL features.

My question is for curiosity. Why a programmer chose to not put into 
his low level language OOP features like in C++ (I am not talink 
about full OOP but a basic subset)
Is this OOP really crap ?

OS APIs and systems don't need that feature. And C++ is not that 
low-level, as you need to use C if you want to use WinAPIs or kernel 
functions.
OOP is a high level feature and no use in low level APIs.

Is this OOP really crap?
 I don't Doc thinks like that, but let him answer.

What I would welcome though is some series capabilities, even blocks, 
traversal, etc. Doc says, it will come via Red. The question is, 
for low level wrappers, if such concept would be usefull or not?

I believe that it will be possible to access all Red datatypes from 
Red/System via the Red Memory Manager (which is being built in Red/System). 
I doubt that Red/System will have any built-in functions to traverse 
and manipulate series though.

I don't think it is useful for Red/System, look at Kaj's bindings, 
its all system structures, API calls, enumerations and a few functions.

When we have Red we (or someone) can write wrappers in Red, so "normal" 
users will not need to use Red/System.

And there is no use series etc. kind of high level features in bindings/API/kernel 
calls.

No object! nor series! support planned for Red/System, remember that's 
supposed to be just a low-level dialect callable from Red meant for 
system programming. However, as Peter mentioned, it will be possible 
to access Red values and actions (mainly series and I/O actions) 
from Red/System when deeper interfacing with Red is needed.


OOP is just not necessary to Red/System, only code and data encapsulation 
is IMO worth adding in the form of a module system. I'm not a big 
fan of intensive use of OOP, as done in C++ or Java (or I'm probably 
just repelled by class-based OOP). I find prototype-based OOP (REBOL, 
Javascript,...) much more appealing and will support it in Red.

As far as I observe, many people are not keen on the C++ implementation 
of OOP, anyway.

Hi Doc,
   I have started the topic just to read your opinion.

   I also have a question. Rebol has manual delegation. Some find useful 
   to have automatic delegation. Which is your opinion about this for 
   RED  ?

By "automatic delegation" do you mean implementing a class-based 
object system? I thought about adding a class! datatype to Red at 
the beginning, but I'm really not convince that would be a wise move.

Doc, I mean calling a method when a value inside an object is set 
or read.

Right, yes, that's a feature I was planning to have in Red (didn't 
know that it was called formally "automatic delegation").

Doc, someone else told me (as far I remember BrianH). I could be 
wrong !

A good and non-ambiguous syntax would be needed for that though.

I thought about implementing some basic series functions in Red/System, 
but they would be primitive and hardly used once the Red memory manager 
is available. There could still be a place for them in low level 
coding, but right now it doesn't justify the effort for me

Giuseppe, those are called properties. The getter/setter functions 
you often find in GUIs are basically the same thing, but properties 
hide that in regular assignment syntax. We don't need getter properties 
in REBOL-like languages because we don't use parentheses to call 
functions, but setter functions appearing to be assignment statements 
might appeal to some.


I've had a lot of experience with properties in languages like Delphi; 
most of the popular languages that currently have property support, 
either in syntax or as a convention, are derived from Delphi. It 
makes code a little easier to write, and a lot harder to debug. The 
main advantage to implementing them in Red or R3 would be to make 
it easier to interoperate with .NET or COM objects.


Automatic delegation is something else. With automatic delegation, 
you automatically forward a method call from one object to another, 
just by declaring it as such. That doesn't really work in REBOL-style 
direct-bound functions because we don't have an implicit self parameter 
(we have self, but it's not a parameter). Red would need to have 
a completely different function binding model for that kind of thing 
to work; which it would likely have anyways, due to it being compiled 
rather than interpreted.

BrianH, thanks for saving me from my ignorance.

If I create struct! inside function and return pointer to that struct 
(as I cannot return struct), how can I get the struct from that pointer?

Structs are always passed and manipulated by reference. You should 
be able to return struct! (unless there's a bug).

This code:

return-struct: func [
	return: [struct!]
][
	s: declare struct! [
		a [integer!]
	]
	s/a: 1
	s
 ]


returns error in compilation:  invalid definition for function return-struct: 
[struct!]

[struct!] is missing its spec block with members definition.

should be: func [ return: [struct! [a [integer!]]] ]

ah, thanks!

An ALIAS is handy for such cases

If I run this code

s: declare struct! [
	f [float!]
]
s/f: 12345678.9
p: as byte-ptr! s
v: p/value
w: 256 * as integer! p/value
x: 256 * as integer! v
print [x ".." w]

I get  this result: 52480..4194304


Why the difference? Shouldn't W and X be same as V is same as P/VALUE?

Leaving for the heavy metal festival. Hopefully on my return on monday, 
there will be some refreshed news towards when Red development will 
resume :-)

Leaving for the heavy metal festival.

 - It's good to see people celebrating parts of the periodic table 
 of elements. Oh, maybe it means something else... :-)

Why the difference? Shouldn't W and X be same as V is same as P/VALUE? 
  I checekd that v = p/value so it would appear to be the type casting 
that is the problem. I checekd the spec and casting a byte! to and 
integer! should be okay. So it seems like it is a bug.

When will they put beer on the periodic table of elements? Hopefully 
after Red is finished?

f: func [
	val	[integer!]
	return:	[struct! [value [integer!]]]
	/local s
][
	s: declare struct! [value [integer!]]
	s/value: val
	s
]

s1: f 1
print ["s1/value:" s1/value lf]
s2: f 10
print ["s1/value:" s1/value lf]

; --- outputs:

C:\code\Red\red-system\builds>test
s1/value:1
s1/value:10


After setting S2 value, S1 is changed. Why? Is it a bug?

Looks like it. Odd

I don't think it's a bug. s is a local (static) variable in function 
'f. f returns a reference to s. So if you change the contants of 
s/value, all references to s will now refer to its new value.

I added prints of s1 and s2 to your program; this is the output :

s1 9348
s2 9348

So how I can return new struct! each time?

Only by declaring the struct! in your main program and passing it 
(its reference) as an arugment:

f: func [
	val [integer!]
	s [struct! [value [integer!]]]
][
	s/value: val
]

Well that's the only way that I've found so far.

Once the Red memory manager is available it may well be possible 
to use it to allocate struct! in a function but then there is the 
problem of how to release the memory later.


From a memory mangement point of view, it seems easiest not to allocate 
variables inside functions to be returned to the calling program/function.

ok, thanks