AltME groups: search

...lit-word and get-word argument...

 - please stop using that misleading terminology. The former is, in 
 fact a "partially evaluated argument", the latter is "unevaluated 
 argument". See the documentation.

lit-word argument would need to be an argument that is a lit-word, 
etc.

Fair enough, I'll try. Those terms only work when you immediately 
follow them with code examples that display the precise meaning. 
Not a bad habit to stick to anyway :)

The declarative forms, like they are written in the specs of a function 
are trully lit-word! and get-word.
I don't understand why you get so upset about that

well, if a "partially evaluated argument" is declared via a lit-word... 
 I don't know why I wound't use the label instead of the definition.

This place is turning into a nit-picking place :-)

Exactly because a "lit-word argument" is an argument that is a lit-word, 
while an "unevaluated argument" is argument that is not evaluated.

Steeve, or a place ruled by religion.

Ladislav, all human languages are highly polysemous.

In the previous contexts, the words : "lit-word argument" may be 
deciphered as:
1) A passed  argument which is a lit-word (your point)
2) An argument that is declared as a lit-word (Brian's point)

The Brian's words are clearly meaningfull in this context, It's only 
you Ladislav who  decided that your personnal semantic representation 
was the only one possible. You couldn't be more wrong.

An argument that is declared as a lit-word (Brian's point)

 - again, an error. An argument, that is declared as lit-word looks 
 as follows:

    argument [lit-word!]


, while an argument, that is partially evaluated is declared as follows:

    'argument [any-type!]

Ladislav's terms are better, in the sense of being more descriptive, 
but I'm unlikely to remember them because I've been using the old 
designations for 10+ years. I'll try, but don't give me a hard time 
if I don't get it at first.

I use "an argument that takes a lit-word" for this:
    argument [lit-word!]

and "an argument that is declared as lit-word" or some variant for 
this:
    'argument [any-type!]

Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 
 - 'argument [any-type!]

But it's ok if you say the contrary, I'm not good enough with enligh 
anyway, so I will not argue against that.

Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 
 - 'argument [any-type!]

But it's ok if you say the contrary, I'm not good enough with enligh 
anyway, so I will not argue against that.

'Ladislav, in the sentence: "An argument that is declared as a lit-word" 
can only apply to 

 - 'argument [any-type!]' - interesting, why do you think so, taking 
 into account, that the meaning of "an argument that is declared as 
 a lit-word" is pretty much standard in many contexts (programming 
 languages), not just in REBOL

Thanks Ladislav,  I know my job very well but I continue to think 
that you're only arguing about: 
- This idea can only be expressed my way with my words.  

You don't recognise the simple fact that same words have different 
meaning inside different contexts.
Vernacular languages are polysemous, it's a fact.

Which distinction you mean?

 - Between a calling convention and a datatype, if the terms overlap. 
 Between the type of a variable, the type of a value, and the set 
 of types accepted by a function parameter, in languages where these 
 concepts are distinct. There's lots of subtle distinctions that need 
 to be made, and for many languages some of these distinctions are 
 different, tied to the particular semantics of the language. REBOL 
 has it worse than most because it's weird when compared to most mainstream 
 languages.

The official documenbation  suffer the same bias. You're reacting 
like a monk in front off the holy bibble.

It's nice to have an official way to express a concept, but that 
doesn't help much if it isn't the common way that the community uses 
to express that concept. It doesn't help to refer to the manual if 
that manual has been rewritten since the last time the person you've 
been talking to needed to read it. Accept that there are community 
standard terms, and hopt that the better terms in the manual win 
out eventually, or at least before the manual is rewritten again 
with even better terms.

Steeve, the bias of using an ambiguous language like English to discuss 
a precise topic :(

what is the fastest way to deep copy a large object?

>> select [1 2 2 3] 2
== 2
>> select/skip [1 2 2 3] 2 2
== [3]

Why the second returns a block?

Oldes, try it with a skip of 3 or 4 to see why a block is returned. 
Not very handy in the 2 case though... but I guess there was a desire 
to avoid special cases.

Darn the R2 version does a copy/part. Silly differences.

>> #[binary! "abc"]
== #{616263}
>> #[bitset! #{010203}]
== make bitset! #{010203}
>> #[block! [1 2 3 4] 3]
== [3 4]
>> #[email! "something"]
== something
>> #[file! "something"]
== %something
>> #[function! [a b] [a + b]]
** Script Error: none is missing its a argument
** Near: func [a b][a + b]

... and so on

The "serialized" word is very inappropriate, e.g.:

    /all "Mold in serialized format"


does not say anything at all, since the format without the /ALL refinement 
is serialized as well (it is a text string).

Some other inappropriate notions:

   "serialized constructors", when used for #[none]


e.g. is a very unfortunate notion, since it is not a constructor 
(=a special function), not to mention, that it surely is not a serialization 
of such a function.

Does serialization not imply there is a reverse action for it? Only 
MOLD/ALL will allow that.

Hmm, that looks like a proper objection, but it does not take into 
account, that e.g.

    123


is a result of both MOLD as well as MOLD/ALL and it surely is serialized, 
while e.g.

    #[none]


is not just "serialized", it is a "specially escaped format", as 
noted by Carl

The unfortunate thing is, that there is the MOLD vs. MOLD/ALL ambiguity, 
which confuses every beginner exactly because when they encounter

    none


they usually think it is a REBOL value of the type NONE!, which may 
mislead them in many cases

the only place that I find use for MOLD is when wanting to preseve 
brackets when displaying a block. otherwise I use FORM or MOLD/ALL

That's not how I originally understood it, when I first read about 
them. Displaying values was the intent with FORM as it does not necessarily 
produce REBOL readable output, but human readable output. MOLD was 
meant to be used for serialization, so that the data could be re-read 
by REBOL.

Indeed, the help strings:

FORM: Converts a value to a string.
MOLD: Converts a value to a REBOL-readable string.

>> print ["==" mold "a^^b"]
== "a^^b"
>> print ["==" form "a^^b"]
== a^b

you mean, when returning a value to the console?

you mean, when returning a value to the console?

 - it is not "returning a value to the console", it is "to display 
 the result of a REBOL expression in the console"

that's different than "human readable output":

>> "a^^a"
== "a^^a"

>> print "a^^a"
a^a
== "a^^a"

I'll rephrase:


What I have a problem with, is that there are apparently degrees 
of serialization:


One that we call MOLD, but doesn't really work on all REBOL data. 
I very rarely use this alone.

One that we call MOLD/ALL, and works on nearly all REBOL data. I 
use this very often.


Then we have FORM, which should work on human readable output. The 
problem with FORM is that it isn't flexible enough. For example it 
should have been capable of reformatting numbers, such as 2E-3 to 
".002". It doesn't do that.

Nevertheless, there is reason to have good native support for any 
numeric format, correct? You and I know that our NLPP app suffers 
performance wise over this, having to use FORM-DECIMAL. Don't you 
think that FORM is a good candidate for assigning it to be only for 
human readable output?

I maybe understand the reason to have things like #[none], #[true] 
and #[false] to specify those values, if someone choose to redefine 
none, true and false.

 - as far as I am concerned, you are missing the point, Geomol. My 
 thoughts:


1) there is a Data exchange dialect in REBOL, which is the main REBOL 
dialect (considering the fact, other REBOL dialects are derived from 
it).


A sidenote: the "Data exchange dialect" name may not be ideal. (this 
name is used in the http://en.wikipedia.org/wiki/REBOLarticle). 
Maybe, following the same "naming procedure" as for other dialects 
we could name it the "Load dialect"?


2) In the Data exchange dialect (or Load dialect, whichever you prefer), 
the

    none


expression is a word, and you do not have any means how to express 
the #[none] value, except for this specially escaped format, the 
same holds for #[true], #[false], #[unset!], etc.

Considering the fact, that any REBOL code is loaded first (in the 
computer, but your brain should follow a similar procedure when reading 
it), i.e. handled as the "Data exchange dialect"/"Load dialect" (pick 
the one you prefer) before being (eventually, but not necessarily) 
submitted to any other interpreting function (like DO, etc.), the 
specially escaped format is useful, since it increases the expressivity 
of the "Data exchange dialect"/"Load dialect" (pick your preferred 
one).

Any, if we define a DISPLAY-RESULT function as follows (in R3):


    display-result: func [value [any-type!]] [print ["==" mold/all :value 
    newline]]

, we obtain:

>> display-result unset!
== #[datatype! unset!]

>> display-result quote unset!
== unset!

>> display-result quote #[unset!]
== #[unset!]

The data exchange dialect is a good point to have constructs. Then 
my logic goes:


REBOL values can be divided in two groups, 1. the ones with a non-ambigious 
lexical representation and 2. the ones without such lexical representation. 
Datatypes of values in the second group include:


unset! none! logic! bitset! image! map! datatype! typeset! native! 
action! routine! op! function! object! library! error! port! event!

and maybe a few more depending on what version of REBOL. The rest 
is in the first group.


It would make sense to have constructs for the values in the 2nd 
group. Then I look at some examples of constructs:

#[string! "abc"] #[email! "[abc-:-d]"]


Those are not necessary. If it's because all values can be represented 
as constructs, then why doesn't this work?

>> #[integer! 1]
** Syntax Error: Invalid construct -- #[


And how would values of type native!, action!, op!, etc. be represented 
as constructs?

I'm not convinced.

REBOL values can be divided in two groups, 1. the ones with a non-ambigious 
lexical representation and 2. the ones without such lexical representation.

 - Well, this is rather confusing for me, since e.g. #[none] is (for 
 me) a "non-ambiguous lexical representation" of the value. But, your 
 classification would be OK with me, if we just added a note like 
 ("when the specially escaped representations are disregarded").

Sorry I answer myself, but it's probably because it gives a different 
kind of value when loaded:

>> load {make logic! 0}
== [make logic! 0
]
>> load {#[false]}     
== false

>> mold/all :until
== {#[native! [[
    "Evaluates a block until it is TRUE. "
    block [block!]
]]]}

I guess, much of my confusion here comes from the fact, that I never 
had the need for constructs.


If we follow the thought, that the none value should be shown as 
#[none] in the console, when it's a result, then the following should 
be shown as well:

>> next "abc"
== #[string! "abc" 2]


I think, most people wouldn't want that. It's not very readable. 
I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.

I see them as necessary, otherwise you would not be able to serialize 
(or specially escape) any rebol code or data properly using a fixed 
method. This is very important for dialects.

Henrik, can you give a simple example, where the serialized format 
is needed?

What's wrong with using a simple SAVE?

Not, if you LOAD the data back into a context, where those words 
have meaning.

It's kinda interesting, how complexity sneak into a language like 
REBOL. I have never used constructs. I save REBOL data and code to 
disk all the time. I even created a file system/database, that is 
all about saving and loading data and code. I get along using a combination 
of simple REBOL functions like SAVE, LOAD, REDUCE and DO.

I understand, it can be argued, it's more simple to just use
	save/all ....
	load ...

than something like
	save ...
	do load ... or maybe ... reduce load ...


but trying to make this simple result in a much more complex language. 
(as I see it)

I'm not sure that's a complexity. It's a basic need, when transfering 
REBOL data somewhere else, using strings or binaries. There is simply 
a loss of information, if the data is transferred in an unserialized 
fashion.

Well, Henrik, I suppose the none word holds the none value, and if 
it does, it probably works as intended. If people want to redefine 
none, then it would mean something else. And then what? I don't see 
a big problem needing constructs in there.

If a writer write
	fromage

what does that mean? In Denmark, it's a dessert, in France, it's 
cheese.

Geomol, you don't know how the data is generated, if you are getting 
the data from disk or network, where you are surely not haplessly 
DOing things for security reasons. You are capturing the state of 
the data. Without such a state capture, much of REBOL is rendered 
useless.

Geomol, you can't present NEXT that way. In that block, it will be 
a word:

>> reduce [:next]
== [action]

Serializing NEXT has no meaning, because it's a native, that already 
exists in REBOL. There is no state we can save with it and there 
is no need to transfer that information.

Ladislav, a better mold/all example is:

>> mold/all reduce [:until reduce [true]]
== "[native [#[true]]]"

What I usually use to differentiate these is that there are literal 
values which do not have to be interpreted (only parsed), and logical 
values which have no real meaning without this interpretation.

Serialization

 in the REBOL sense, hence the quotes,  is used to give the second 
 form of data a way to be described in the first, *where its possible* 
  which it isn't at all in the case of some types (native,etc) and 
 only partially in others (objects!, functions!, etc.)   


even with these distinctions there is still a sizeable amount of 
REBOL *data* (interpreter values, not human visible source code) 
which cannot be serialized (in the real sense) in any way because 
either:  

-the notation has simply not been defined for it (cyclic series/objects, 
which is serializable in other languages)

-it implicitely depends on its interpretation (a VID dialect block 
(you cannot save the vid from the faces)), custom types (in the future))

so the way I see it is that: 
-MOLD is the counterpart to DO
-MOLD/ALL is the counterpart to LOAD.

which leads to saying that:

only MOLD/DO can effectively represent all data,  (with the caveat 
that it is extremely insecure)

only MOLD/ALL can effectively represent literal data without interpretation 
(with the caveat that it is not complete)

BOTH , are highly complex to use effectively in non-trivial cases. 
  


IMHO, if it's notation where completed, the second form could actually 
be built to represent all data, since it could be built to include 
binding hints, series reference graphing and more.  It doesn't have 
to be pretty, it just has to be symmetric.

I think, that the point here is the Geomol's question:


I still ask myself, if all those constructs are really necessary 
taking the amount of work and time used into account.


The answer is quite simple, it is as with any data the Load dialect 
can represent:


- many data representable by the Load dialect aren't "really necessary"

-- other languages can usually represent less data types than the 
Load dialect can

-- the Load dialect did not have the escaped format from the start, 
and could do without it


- without the escaped format, the Load dialect cannot express values 
of the logic! type


- it is useful to be able to express values of the logic! type in 
the Load dialect
-- some languages have the advantage of being able to do that

-- it is confusing to use a word like true in the Load dialect, when 
meaning the logic value, since in the Load dialect true is a word, 
not a logic value (notice the example, where Geomol confused words 
and their values)

-- the expressibility of the logic! datatype in the Load dialect 
enhances the expressivity of the dialect, which is why it is useful 
to have it, similarly as for any other datatype expressible

-- the expressibility of the logic! datatype enhances the reflexivity 
of REBOL, since 

--- this way, the Load dialect can express values that would be otherwise 
inexpressible in it, while being used in the Do dialect

--- that means, that the Load dialect would not be usable to "speak 
about" logic values in a direct way

That was my answer as far as the usefulness of the #[true] and #[false] 
values is taken into account. Similarly, the usefulness of #[unset!] 
and #[none] is quite unquestionable. As far as the usefulness of 
the other representaions goes, it may be more questionable to have:

- escaped format for objects, because

-- some objects are not describable precisely enough using the current 
escaped format

-- nevertheless, the ability to describe a result of a REBOL expression 
this way is useful at least sometimes, since for me, the #[object! 
...] clearly communicates e.g. the fact, that it is one value, while

--- make object! [...] are, in fact, three values in the Load dialect, 
as Geomol noticed


- similar notes can be written about the escaped format for the function! 
datatype


- the escaped format for natives, (which exists only in R3) is even 
less useful, since it is not loadable, so, in a strict sense of the 
word, it is not even in the Load dialect

-- but (arguably) it can still be used to describe a result of an 
expression when such a demand occurs

The only problem right now, is that the serialized form of the language 
is just not complete. all the edge cases I can think of have a way 
of being resolved, especially in R3.

having cyclic references be checked and used on object/block types 
would already go a very long way.


#[block  1  [ val1 val2 ...]] ; serialized block with uid as first 
parm (only needed when it is shared in the string being loaded).
#[block  2  [ val3  #[block 1]  val4]  ; shared block
#[block  3  [ #block 3 ]]   ; self-reference


effectively shows a simple way to solve the cyclic series/object 
problem.

Moreover, when I look at it, I have to say, that it actually would 
not be acceptable, since when you do want to mold e.g. your block 
3, you should obtain a representation of one block

You forgot to mention: Natives, actions and ops aren't properly serialized 
for a couple reasons:

- The native references wouldn't necessarily be valid between versions.

- It breaks the security constraints, giving access to natives without 
requiring access to their contexts.

Today's Moment of REBOL Zen:

>> s: "abc"
== "abc"
>> t: copy next s
== "bc"
>> index? t
== 1
>> b: []
== []
>> insert b next s
== []
>> index? b/1
== 2
>> p: copy/deep b
== ["bc"]
>> index? p/1
== 2


So copy/deep a block does not use copy on each member of the block 
in the normal sense of copy.

When copying a string, you get what you see.

When copying deep a block containing strings, you get more than what 
you see.

Don't know, but it would be a problem now, because I use this behavior 
to hide data in blocks (like absolute identifiers)

You have a point here

Ok, I agree, it's a problem for 
>> same? y/1 next s
== false

Good point Geomol, you found a new ticket

yes, the whole serie is copied from HEAD in the copy/deep case...not 
sure if Carl does that intentionally but could be a bug that can 
lead to unwanted bigger memory footprint in some scripts imo.

Ladislav, typical serialization only takes into account the data 
traversed (in the order it meets it).  in the above example, if the 
block 2 was encountered first, then it would look like this:


#[block  2  [ val3  #[block  1 [ val1 val2 ]]  val4]  ; shared block 
containing another shared block
#[block  1 ]


(I kept the ids, just to make the comparisons easier, but it would 
have effectively swapped 1 and 2)


I built such a system for a project a long time ago (I lost the code, 
unfortunately).   It stored graphics in block formats, and used shared 
sub-blocks in many objects .  So  I built a reference-safe load and 
save which completely made the above invisible... I used tags to 
refer to blocks, and  a tag-based block serialization which was very 
similar to the above.  it was quite specific to my application, but 
it could have been generalized.   I did have to make it a two-step 
process.  if it where internal, it could be done in a single pass.


 a serialization can be made more persistent (accross several serializations 
 and even sessions), but that is not what REBOL is built for, nor 
 would it be very useful within REBOL's semantics IMHO.

unless someone finds a better alternative, I don't see anything wrong 
with this syntax... maybe it needs a bit more components (like keeping 
tabs on the index of the block).  
in fact  maybe this is even better:

 #[block  #1 2 [ val1 val2 ]] 


here an issue type is used for the uid and the integer is used as 
the block index.

since this is just managed within LOADing, it shouldn't force the 
word count to increase, its just a notation.

I solved the problem of serializing circular blocks etc. a long time 
ago, by adding DISMANTLE and REBUILD. Eg. see http://www.colellachiara.com/soft/YourValues/libs/persist.r

So, it can even be done as a mezz layer above MOLD and LOAD.

this works to a point whereupon you start getting overflow

Max - thanks :-) I wonder why there is a difference between the 'difference 
and substraction ....

I have a COPY/DEEP question:


When doing a COPY/DEEP, the first level requires that the argument 
must be a series!, port! or bitset! But when doing a /DEEP, I imagine 
that COPY traverses a series for elements and uses a different process 
than for the first level to determine whether the element can be 
copied. If it can't, it silently passes the value through.

Why can't we do that on the first level as well?

I'm not really sure I want to, but I think it's interesting that 
there is a difference between the first level and other levels.

I do dislike having to do:

either series? var [copy/deep var][var]


thing. Generally the programming needed for absolutely deep copy 
a value is too elaborate.

I try to think of situations, where I would need to do that. I also 
don't think, I do it often. But it's an interesting idea. I try to 
come up with some situations, where I need to copy a value, that 
can sometimes be a series, sometimes not. Hmm...

Let's see: I need to copy a value, and it can be any value, so copy 
should work on any value. I don't see a flaw in that. I wonder, if 
it has come up before?

Well I'm not against that, for sure. It's an,old debate.
I dislike annoying type checking errors messages. 

My point is that if a primitive function can't deal with a data type, 
the data should just pass thru silently.

But other peoples will object that error messages are favored for 
educationnal purposes... Uh !?

But year after year, I see that more and more functions have been 
corrected to be tolerant.
A good example is REDUCE

And yeah Geomol, COPY should act just like REDUCE.
if the input  is not a serie, it should just return it.
It would save lot of useless checking code in our script.
And lot of others functions should behave like that

There is a lot of type checking in REBOL. I feel too much sometimes. 
Calling many functions involve two types of type checking, as I see 
it. Take ADD. Values can be: number pair char money date time tuple
If I try call ADD with some other type, I get an error:

>> add "a" 1

** Script Error: add expected value1 argument of type: number pair 
char money date time tuple

I can e.g. add pairs:

>> add 1x1 1x2    
== 2x3

and issues:

>> add 1.1.1 1.2.3
== 2.3.4

But I can't add a pair and an issue:

>> add 1x1 1.2.3
** Script Error: Expected one of: pair! - not: tuple!


So that's kinda two different type checking. First what the function 
takes as arguments, then what actually makes sense. If the user also 
need to make type checking, three checks are then involved. It could 
be, the first kind isn't done explicit for natives, and that it's 
kinda built in with the second kind. But for non-native functions, 
the first type checking is done:

>> f: func [v [integer!]] [v]
>> f "a"
** Script Error: f expected v argument of type: integer

Perhaps because it's a complete word, rather than an abbreviation?

English is probably too lenient. to say for sure :)
If you do a websearch for....
  "next back" button

....You'll see next and back are a common choice of names for navigating.

I came across a funny thing with binding. We've learnt, that the 
binding of words in a block is done, when the words are put into 
the block. This little example with two functions illustrate that:

blk: []

f: func [
	v
][
	insert blk 'v
	g v
]

g: func [
	v
][
	if v = 3 [exit]
	print ["v:" v]
	probe reduce blk
	g v + 1
]


F puts the word V into the block, then calls G, that has its own 
V. When G reduce the block, we see the original value of V from F, 
even if Gs V is changed:

>> f 1
v: 1
[1]
v: 2
[1]


Then I tried this next function, which puts V in the block in the 
start, then call itself with changed V value:

f: func [
	v
][
	if v = 3 [exit]
	if v = 1 [insert blk 'v]
	print ["v:" v]
	probe reduce blk
	f v + 1
]

>> clear blk
== []
>> f 1
v: 1
[1]
v: 2
[2]


This time, we see the latest version of V. The first V, which has 
the value 1, was put in the block, and it's still there somewhere 
in the system, but we get the V value from the latest F.

Is this a problem or a benefit, or is it just a bit strange?

the binding of words in a block is done, when the words are put into 
the block
 I don't think this is true. See:
x: 10
blk: []
o: context [x: 20]
insert blk 'x
insert blk in o 'x
reduce blk
== [20 10]

the binding of words in a block is done, when the words are put into 
the block
 - that certainly is false

Cyphre, in your example, when you insert the first x in the block, 
it's the x holding the value 10. To me, the x in the block is bound 
to the outher x at the time, you insert it into the block. The next 
x, you insert in the block, is the x from the context o. So at the 
time, you insert it into the block, that x in the block is bound 
to the x in o.


So the block holds two different x, and they're bound at the time 
of insertion. That's what I meant, when I said "the binding of words 
in a block is done, when the words are put into the block".


(Words can be rebound at a later time using e.g. BIND, but I'm not 
looking at that in these examples.) I don't have time and energy 
to argue with Ladislav right now. :)

Ladislav, I took a quick review of your "Bindology". What I mean 
correspond well with what you write in:
http://www.rebol.net/wiki/Bindology#Scope

The bug illustrated at the end of
http://www.rebol.net/wiki/Bindology#MAKE_OBJECT.21
is interesting! :)

That bug is really weird! I put in some prints to show, what's going 
on:

f: func [x] [
    get in make object! [
        a: "ok"
        if x = 1 [
            a: "bug!"
            print ["f 2 :" f 2]
            a: "ok"
        ]
		print ["a:" a "x:" x]
    ] 'a
]

When I run it, I get:

>> f 1      
a: ok x: 2
f 2 : ok
a: ok x: 1
== "bug!"

I can't get my head around, what's going on internally.

You're right, I missed your point about recursion. As I understand 
it, the behavior you're observing is caused by function context values 
being pushed on stack on recursive calls, as showed by Ladislav's 
simulation (http://www.rebol.net/wiki/Bindology#Model_of_function_evaluation
). So the value of 'v word bound to 'f context, inserted in a block 
and evaluated later, depends on the "current" level of 'f function 
recursion.

Yes, you got it. Thanks!

I'm not saying, this is a bug, I'm just wondering about the behaviour. 
It might actaully be seen as a benefit, as this gives us 2 different 
behaviours depending on, if we use recursive calls or call another 
function (which can then be recursive), like the G function in my 
original examples.

It looks like a side-efffect of the implementation, I do not think 
that this behavior was planned as a feature. I guess some recursive 
algorithms could benefit from it, but I fear it can quickly lead 
to code that is hard to maintain.

Are there other high level languages (or maybe interpreted languages), 
that can put references to variables into tables? I took a look at 
Python and Lua, but I don't think, they can.

Anyway, the explanation is as follows: since the function F is called 
twice, it creates two objects having the attribute A. While the first 
object has got the attribute A set to "ok" initially, it ends up 
having the attribute A set to the "bug!" string before the F is called 
for the second time. After the second call to the function F occurs, 
the function does not "see" the first object's A attribute when setting 
the A using the a: "ok" expression.

Regarding "There are several versions of V, one for each call to 
F" - the fact is, that there is only one version of the word 'V, 
not "several". If you wanted to have "several versions of V" you 
could have used a closure, as is demonstrated later.