RE: A question about certain language features
-------Phoenix-Boundary-07081998-
Chris wrote on 3/21/02 11:18:34 AM:
>
>With your implementation, it is nessecary to perform checks everytime a
>PBR variable is expressed.
>
>If the PBR is declared when the paramter is declared, instead of when
>it's accessed, then those checks can be eliminated.
>
The checks I am referring to are those that take place at runtime.
The assignment operation, for example must check at runtime to see if
its arguments are appropriate, and to chose the method to implement
the operation. Rob has done an absolutely amazing job of accomplishing
this in a minimum of machine cycles; unfortunately that means that
ANY change is a substantial hit on performance.
Adding a reference type entails creating a new basic type to Eu, which
in turn requires changes to the input scanning, the parsing, the runtime
handling of a number of operators, the memory allocation and garbage
collection. As I said, deep changes.
The way I implemented PBR was an attempt to get around these problems,
but the result was not a general solution. It only worked for modification
of the elements of a sequence, assignment or other modification of
the sequence as a whole caused reversion to PBV.
This partial solution may still prove useful for structures and classes,
whose structure should not be changeable anyway.
>As a solution to the difficulty discerning between PBR and PBV, PBR's
>should be modified through special routines. This would help
>readability, because people would know when they see the assignment,
>that it is PBR, and not a PBV.
>Something like: set_var(arg,get_var(arg)+10)
>
>I think this is the main reason for any confusion between PBV and PBR.
>
>Yeah, it aint pretty, but I don't think it's possible to make PBR
>esthetically pleasing and still keep all the functionality.
>
This might be possible, but you are right about its beauty.
Might be useful for porting Basic into EU?
>Only routines would allow for PBR. Wouldn't the routine be optimised by
>the interpreter during parsing? Each routine is read in before it's
>executed. It's not inline code. I don't see the need to have any checks
>at runtime.
What about 'foo(s[2])'? What is it sending to foo()?
Can't tell at compile-time.
>
>Personally, I am not enthusiastic to see EU with PBR. I suggested PBR
>before as a solution to being able to modify variables in type defines
>ONLY. No PBR for other routines. If you want PBR in a regular routine,
>declare it as a function and pass the modified variables as the result.
>You can't do that with type defines.
>
I see two reasons for PBR:
1) A tool exposed to the programmer to assist in porting other
languages to Eu.
2) A hidden capability used internally to implement structures (sequences
with imutable structure) and classes (structures with methods)
-------Phoenix-Boundary-07081998---
|
Not Categorized, Please Help
|
|
