codeblock decompiler - Clipper

That is a very neat trick Przemek, thanks for sharing

"Przemyslaw Czerpak" wrote in message
news:slrnf7kv44.tb8.druzus@localhost.localdomain...
> proc main()
> local n, a, b
> n:=1
> a:=detachedblock(n)
> n:=2
> b:=detachedblock(n)
> n:=3
> ? eval(a)
> ? eval(b)
> return
>
> func detachedblock(n)
> return {||n}

the n arg in detachedblock() is a local copy of the caller parameter, and
doesn't change inside detachedblock, so it is protected from content
changes in main; that does it!

great technique

> If you are using Harbour then you can also controll references in such
> code, f.e.:
>
> proc main()
> local n, a, b
> n:=1
> a:=detachedblock(n)
> n:=2
> b:=detachedblock(@n) // pass n by reference
> n:=3
> ? eval(a)
> ? eval(b)
> return
>
> func detachedblock(n)
> return {||n}
>
> and in such case block inside 'b' will share the 'n' value with local 'n'
> variable of function main(). But this works only in Harbour and is not
> supported by Clipper and xHarbour.

in xBase++ <cb>:eval() provides an additional arg controlling whether
something is passed as a reference back, but i haven't any docs on that;
do you happen to know what they mean exactly and how it works?

frank

On Fri, 22 Jun 2007 14:26:05 +0200,
frank van nuffel <nospam@versateladsl.be> wrote:
> in xBase++ <cb>:eval() provides an additional arg controlling whether
> something is passed as a reference back, but i haven't any docs on that;
> do you happen to know what they mean exactly and how it works?

I do not know what difference is between <cb>:eval() and eval(<cb>)
in xbase++ - I've never used it.

In Clipper, Harbour and xHarbour code like:
eval( <cb>, <args,...> )
is internally translated by compiler to:
<cb>:eval( <args,...> )
and then PCODE is generated. In [x]Harbour it's exactly the same
PCODE for both versions in Clipper it's not exactly the same but
the difference is minor. In both cases the references are fully
respected.

best regards,
Przemek

On Fri, 22 Jun 2007 13:32:18 +0200,
sali <sali@euroherc.hr> wrote:
> terrific!
> but it makes me confused. what is the real variable referncing mechanism
> used by the codeblock?

In Clipper local variables used inside codeblock are "detached" from
VM stack so when they are out of scope they are not removed but replaced
by new one(s).

> in the first [mine] examples, i understood that codeblock is referncing
> *variable slot*, so the content of that variable slot was used at the time
> codeblock being evaluated.
> but, in your detachedblock() func, codeblock is referncing variable slot
> which is going to disapear in the future.
> but, in the moment of codeblock compilation, compiler may not be aware of
> that fact.
> it seems like codeblock is referncing *both* variable slot *and* keeps
> variable's value *frozen* in some internal stack.
> later, if variable slot goes out off the scope, it uses frozen value.
> or something like that?

Not exactly. I do not know what _exactly_ Clipper does though I have
some ideas after ****yzing some side effects during execution of code
compiled by Clipper but instead of creating some speculation I can
describe how it's done in Harbour.
When code block is created and access some local variables then new
variable with reference counter is allocated and initialized with value
stored in local variable, in Codeblock is stored a reference to this
variable and then on HVM stack original local variable is replaced also
by such reference. Very simple and effective mechanism - when both
references will have been cleared then the allocated variable is freed.
That's all. It can be improved a little bit and I plan to implement
automatic detaching on function exit in the future so it will be even
simpler.

> it seems to me quite complicated.

This is very simple. Thing about garbage collector and freeing item
containing arrays and/or codeblocks with cyclic references. This is
much more complicated.

> i more like simple rules, like c-language does:
> if refernce_ok, then do_it, otherwise do_gpf

and this is one of the reasons why people do not use C for everything.
It's very easy to break module A due to typo in module B. I know C quite
well and I wrote a lot of C code in my life but I know that I have to
be _VERY_ careful when I'm using C and it causes that I'm much less
efficient in some type of code.

But if you realy want to break Clipper then it's also possible.
First try this code:
proc main()
local a, b
a:=0
b:={@a}[1]
? a, b
++a
? a, b
++b
? a, b
return

Interesting, isn't it?
Then make sth like:
func arrRef()
local a, b, c, d, e, f
return { @a, @b, @c, @d, @e, @f }
and then if you add to your code:
aRef := arrRef()
Then you will have array with 6-th references to unused VM stack items.
Very bad effect and well designed upper level language should not allow
to make sth like that or it should be safe. It's additional reason why
I want to add automating local detaching to Harbour - it will make such
code safe because the references inside the above array will be detached
when arrRef() will exit.

> i think that norton guide delivered with c53 is missing some important parts
> regarding technical details of internal data structures like arrays and
> codeblocks and objects as well

There are many different things not documented in NG but existing in
Clipper but AFAIR local detaching was described in Clipper's manuals.

best regards,
Przemek

On Fri, 22 Jun 2007 15:24:28, Przemyslaw Czerpak <druzus@nospam.please>
wrote

>In Clipper, Harbour and xHarbour code like:
> eval( <cb>, <args,...> )
>is internally translated by compiler to:
> <cb>:eval( <args,...> )
>and then PCODE is generated. In [x]Harbour it's exactly the same
>PCODE for both versions in Clipper it's not exactly the same but
>the difference is minor. In both cases the references are fully
>respected.

I haven't looked at this in years, but I don't think the difference is
minor for Clipper 5.2e. I distinctly remember getting problems when
using the cb:eval(x) syntax instead of eval(cb,x).

--
Doug Woodrow