• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[#Red] Red language group

DocKimbel
5-Jul-2012
[616]
Right, yes, that's a feature I was planning to have in Red (didn't 
know that it was called formally "automatic delegation").
GiuseppeC
5-Jul-2012
[617]
Doc, someone else told me (as far I remember BrianH). I could be 
wrong !
DocKimbel
5-Jul-2012
[618]
A good and non-ambiguous syntax would be needed for that though.
Kaj
5-Jul-2012
[619]
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
BrianH
5-Jul-2012
[620]
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.
GiuseppeC
7-Jul-2012
[621]
BrianH, thanks for saving me from my ignorance.
Rebolek
10-Jul-2012
[622]
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?
DocKimbel
10-Jul-2012
[623]
Structs are always passed and manipulated by reference. You should 
be able to return struct! (unless there's a bug).
Rebolek
10-Jul-2012
[624]
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!]
DocKimbel
10-Jul-2012
[625x2]
[struct!] is missing its spec block with members definition.
should be: func [ return: [struct! [a [integer!]]] ]
Rebolek
10-Jul-2012
[627]
ah, thanks!
Kaj
10-Jul-2012
[628]
An ALIAS is handy for such cases
Rebolek
11-Jul-2012
[629]
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?
Pekr
11-Jul-2012
[630]
Leaving for the heavy metal festival. Hopefully on my return on monday, 
there will be some refreshed news towards when Red development will 
resume :-)
Henrik
11-Jul-2012
[631]
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... :-)
PeterWood
11-Jul-2012
[632]
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.
Arnold
11-Jul-2012
[633]
When will they put beer on the periodic table of elements? Hopefully 
after Red is finished?
Rebolek
11-Jul-2012
[634]
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?
Kaj
11-Jul-2012
[635]
Looks like it. Odd
PeterWood
11-Jul-2012
[636x2]
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
Rebolek
11-Jul-2012
[638]
So how I can return new struct! each time?
PeterWood
11-Jul-2012
[639x3]
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.
Rebolek
11-Jul-2012
[642]
ok, thanks
Kaj
11-Jul-2012
[643x2]
Oh right, the pointer is returned from the function, not the value
There's no problem in allocating memory to return from a function, 
but you have to use ALLOCATE and later FREE it
Rebolek
11-Jul-2012
[645]
Ok, so this version does what I expected :)

f: func [
	val	[integer!]
	return:	[struct! [value [integer!]]]
	/local s
][
	s: declare struct! [value [integer!]]
	t: allocate size? s
	s/value: val
	t: copy-memory t as byte-ptr! s size? s
	as struct! [value [integer!]] t
]

s1: f 1
print ["s1/value:" s1/value lf]	; == 1
s2: f 10
print ["s1/value:" s1/value lf]	; == 1
Kaj
11-Jul-2012
[646x5]
You don't have to declare an intermediate struct and copy it
t: as struct! [value [integer!]] allocate size? s
t/value: val
t
You should check the allocation for being a null pointer, though
Rebolek
11-Jul-2012
[651]
how that can happen?
Kaj
11-Jul-2012
[652x3]
If you don't get the memory from the operating system
The form-* functions in the C library binding do pretty much that:
http://red.esperconsultancy.nl/Red-C-library/artifact/a1a55e070454c421657185b1d9d09f480d6c5587
Rebolek
12-Jul-2012
[655]
Another question :) Is there any easy way to convert integer! to 
float! ? I wrote something for float! to integer!, but with integer! 
to float! I'm bit lost.
Ladislav
12-Jul-2012
[656x3]
Another question :) Is there any easy way to convert integer! to 
float! ? I wrote something for float! to integer!, but with integer! 
to float! I'm bit lost.
 - see http://www.fm.tul.cz/~ladislav/rebol/library-utils.r
The approach is as follows:
1) convert integer to double (=decimal!)
2) convert double to float
aha, sorry, this is a Red group...
Rebolek
12-Jul-2012
[659x2]
yes, I'm looking for Red/System solution.
Why does this code throw *** Runtime Error 11: float stack check 
?

i: 0
f: 0.0
p: declare pointer! [float!]
arr: allocate 100

while [i < 10][
	p: as pointer! [float!] arr + (i * 8)
	p/value: f
	f: f + 0.1
	i: i + 1
]
Kaj
12-Jul-2012
[661x5]
Sounds like a bug, although the program is overly complex
i: 0
f: 0.0
arr: as pointer! [float!] allocate 10 * size? float!

while [i < 10][
	p/i/value: f
	f: f + 0.1
	i: i + 1
]
That should work, and be more secure
arr/i/value: f
Oh, with path notation, you need to adjust the loop to start counting 
the index from 1