OpenEuphoria

1. Assignment Question

• Posted by Mario Steele <eumario at trilake.net> Feb 25, 2005
• 488 views

Allright, I know this may be a stupid question, but it actually has a purpose,
cause this is really bugging me how the '$' operator messes up everything.

Why do I say that?  Well, follow these examples

Example 1:

integer a
a = 1

>From reading this, we know that 'a' is declared as a variable, and that
variable is an integer.  Plain and simple, right?  Next step, we move to an
assignment operation, where we are assigning '1' to 'a'.  Now, there's more
to it, then what I'm about to explain, but just hang in there, cause it'll
get more intresting here in a sec.

Internally, it's determined that we're assigning the value 1 to the variable
namespace of 'a'.  Between the decloration of the variable namespace, the
assignment operator, and the actual value, there's a type-check done on '1'
to ensure that it'll fit in 'a', EG: we make sure that '1' is an integer,
and if it is, assign it to the variable, otherwise, we tell the user that
they are trying to put in the wrong type of data, into the variable.  Now,
is this, or is this not correct?

We move on to Example 2:

integer a
a = 5 + 1

Now, this one is a bit more difficult, cause now, we're doing mathmatics in
the assignment statement.  But, the thing is here, how does the interpreter
know that the value that 'a' should get, is '5 + 1', and not '6'?  Well,
like before, this isn't exact, but first, the RHS get's evaluated, since it's
an expression, not a litteral.  Meaning, that since it found the operator
'+', it now knows that '5' and '1' needs to be added together, before finally
assigning it to the variable namespace 'a'.  Meaning now, that instead of
simply just assigning, we actually need to evaluate what the programmer means
when they do this.

Next Example:

function GetValue()
    return 5
end function
integer a
a = GetValue()

Again, we have the basic decloration of the 'a' namespace as a variable, and
we have an assignment.  But, we come back to the same problem, how do we know
that the user doesn't want to put 'GetValue()' into a?  Cause the interpreter
knows, that it's earlier declared as a Function, and again, it catches the
fact, that it's a expression, that needs evaluated, before finally assigning
the data to a.  If 'GetValue()' was a procedure, it would get evaluated, and
break out, cause no data is returned from 'GetValue()' as a procedure.  And
again, the interpreter has to evaluate the final return value, to ensure that
the value can be put into the namespace, 'a', EG: it must be a integer.

Final Example:

function GetValue(integer b)
    return b + 1
end function
integer a
a = GetValue(5)

This example, adds more complexity, but it remains the same, except for the
fact, now GetValue has a Private Member Space, in which 'b' is assigned to,
The interpreter knows, to assign 'b' the value of '5', cause of the order
of the arguments.  Meaning basically, that 'integer b' and '(5)' becomes
'integer b  b = 5'  And the interpreter knows that it can't return the
litteral 'b + 1' from the call, cause it knows that 'b + 1' is an expression
which was evaluated first, before returning it to the caller, which in this
case is 'a = GetValue(5)'.

Throughout all of these examples, the interpreter didn't need to evaluate
'a' or 'b', cause it allready knew they was variable namespaces, and it knew
that they was an integer, only cause there was a need to assign data to it,
and when it came down to it, the RHS had to be evaluated first, before the
left hand side was.

So, Rob, you stated before, that it's not documented the exact behavior of
the interpreter, when you add something to a global sequence, from another
routine, we just experimented, and it worked that way.  Well, it worked that
way, because it's an expression, and the interpreter knew that.  It knew it
needed to evaluate the expression first, before Type Checking the data, and
finally assigning the data to the variable.  The only difference now, is the
fact that instead of us pulling the rug out from under you, you've pulled
the rug out from under us.  I guess my question is now, since this "feature"
was implemented, are we to expect that the way the rest of the assignments
are done, are going to change as well?

Mario Steele

P.S.  Before anyone get's the wrong idea, I am not trying to beat down on
the interpreter, or the language construct, or Rob for that matter,
I am just pointing out a few things that are "Givens" in the Euphoria
Language, that don't need to be documented, cause they are the Basic
programming principals.

3. Re: Assignment Question

• Posted by cklester <cklester at yahoo.com> Feb 25, 2005
• 469 views
• Last edited Feb 26, 2005

Robert Craig wrote:
> 
> I think you'll find the $ feature to be very convenient, 
> as well as promoting readability and efficiency.

I used my first instance of var[$][$] the other day. That was nice. :)

-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/

5. Re: Assignment Question

• Posted by Mario Steele <eumario at trilake.net> Feb 26, 2005
• 488 views

Okay, going in reverse order here....

Pete:  I said that's the way I view it, and expressly stated that it might
not be the way that the Interpreter handles it.  That is part of the first
paragraph in my post.  To me, that would be the way to do it, as a Logical
thinker.

Robert:  I understand this, however, I have now ran into the problem, where
for some reason, doing the method of
new_isntance = new(class,args)
class[instance][member_instance][member_value] = new_instance

The instance that I'm now assigning the value to, dis-appears on this
instruction completely.  Hence why I'm now re-writting my entire library.

This time, I'm re-writting it to create the variable data, as needed, through
recursive calls to a "NewObject()" function, which creates all the data as
nesscary, and returns to the caller the Data that it done.  This brings a
new complexity to the entire library.  Why do you ask that this brings
complexity?

Simple:  Garbage Collection

Simply put, when a user destroyes a Object from the Library Memory, it would
simply put a -1 at that point, EG:

ObjectClass = {"MyClassA","MyClassB","MyClassC","MyClassD"}
destroy(3)
pretty_print(1,ObjectClass,{3})
-- Prints Out:
-- {
--   "MyClassA",
--   "MyClassB",
--   -1,
--   "MyClassD"
-- }

Now, the way I'm writting it, is actually becoming a burden to understand,
and figure out where it's going, cause now, I have to seperate this into
several diffrent functions, that not only create the "Temporary" data, but
also have to figure out where to place it in the sequence.  Then, once all
the data is gathered, I have go to through a loop of the said data, and find
every occurance, and actually store it at that placement.

Again this brings a complexity to the code, that should actually be easy to
understand, under the old method, rather then through the new method.

Not saying that the '$' code isn't convient, it proabbly is, considering I
don't use it, I can't officially have my likes, or dis-likes about it.
Reason why I don't use it, is cause I try to be as backwards compatable with
2.4, since it seems quite a few people are gonna be pleased with that version
or version 2.3, in order to keep their code simple.

As quite a few people said to me Robert, you follow your leader's impression.
You give off the impression of keeping the coding easy for yourself, and you
can't very well expect us not to do the same.

Mario Steele

7. Re: Assignment Question

• Posted by Mario Steele <eumario at trilake.net> Feb 27, 2005
• 459 views

Robert Craig wrote:
<snip>
> You just have to split your original statement into
> two smaller statements, using a temp variable. 
> Why are you now rewriting your whole program, 
> and suggesting that 2.5 is to blame for all your problems? 
> I don't get it. Your program must have other problems, even on 2.4
> or earlier.

Actually, no, it works perfectly fine on 2.4, and the reason why I'm re-writting
it, is cause indicies still dis-appear on me, EVEN using the temp variable,
before assigning to the sub-script.  This time though, it's not the last
part of the sequence that I just added that dis-appears, it's the one I'm
assigning the temp variable to.  And it doesn't dis-appear till the
assignment statement is executed.

EG:
MySequence = {1,{2,0},4} -- after execution of CreateObject() or something
MySequence[2][2] = tempVar -- Kablooey, cause MySequence is now {1,4} for some
reason.

I've went through the trace facility, to confirm this, and it does
dis-appear.  But, since I deleted that code in a fit of anger, and didn't
make no back-ups, it's lost.

I'm sure, somehow, the thing will happen again, just that now the way I have
the code re-wrote, it will work just fine, so I guess it'll work this way.

Mario Steele

9. Re: Assignment Question

• Posted by Mario Steele <eumario at trilake.net> Feb 27, 2005
• 464 views
• Last edited Feb 28, 2005

Juergen Luethje wrote:
<snip>
> Mario, what shall I do now? Do you expect me (and some other hundreds of
> people) to believe now that Euphoria 2.5 is broken, and we can't rely on
> it? Or shall I ask you to prove what you are claiming, i.e. give us some
> concrete running Eu code, that does what you are reporting, and allows us
> to reproduce what you had observed?
</snip>

When I write new code, that does the same thing, I'll be more then happy to
submit it to the forum, so that everyone can see the problems I am 
encountering.  But till then, it's next to impossible for me to show what
is happening.

<snip>
> So you can't prove it? Then -- at least for me personally -- posts like
> this do nothing else but create confusion and uncertainty. 
</snip>

Not at this time, I cannot prove it, however, the only reason why I post
these messages, is so that others can be somewhat aware of the problem. And
not just sitting there, saying, "Okay, what the hell just happened to my
program???"

Mario Steele