Re: Structure Pre-Processor
Bernie wrote:
> PETE
>
> What are all of the characters at end of your e-mail on listserver ??
>
> I presume they are some sort of attachment. How Do you decode them ??
>
> I use EUDORA for my e-mail .
Sorry. I forgot that Pine sometimes encodes attachments that get mangled
on the way through the listserver. It was supposed to be type TEXT-PLAIN.
I've posted the file to my webpage if you still want it.
Ralf wrote:
> Interesting approach. This way we do have the speed benefit, that comes
> with structures.
> You say 'scope not enforced', but the scope is already enforced by
> Euphoria.
Yeah, I guess Euphoria does catch some of the errors, but spp still
thinks all structure variables are non-local to routines...
somestruc a
function b()
anotherstruc a
....
end function
a.whatever -- the preprocessor assumes the type of "a" to be
-- "anotherstruc", not "somestruc" as expected. But it
-- only displays useless warnings, and will still translate
-- it to something usable.
> The only real 'issue' that I can find is that we are not able to express
> the whole structure or parts of it.
> But this can be solved as well, I think. I see three options:
Yeah, I'd like to be able to express a structure as a whole as well...
> 1) When we use the whole structure, just built it up:
> { my_structure_item1, my_structure_item2 }
> Note: WHen we assign something to it, we would need to use some
> dummy variable.
> However, this is *slow*
something like:
structure rgb integer red, green, blue end structure
rgb color
color = {100,150,200}
should translate to:
color_red = 100
color_green = 150
color_blue = 200
or in the case of not having a bracketed sequence,
color = somefunction()
to:
junk = somefunction()
color_red = junk[1]
color_green = junk[2]
color_blue = junk[3]
Reading a whole structure could be pretty easily translated:
? color
to:
? {color_red, color_green, color_blue}
> 2) Always keep the decleration of a variable (using a structure)
> global. And have a little function to retrieve and set the structure.
This could get messy... I wouldn't want to try it.
> 3) Use at least one level of slicing. That is, structures in
> structures, etc. are automatically resolved, only the
> first-top-level of the structure is a sequence. Maybe a little database
> managed by an external library.
This sounds overly complex.
> Faster than the above options. Esspecially since the slicing
> could be partly 'optimized' away, by efficiently lookup and
> store values in the sequence, only when needed.
Slicing a structure? I don't get it.
> Oh, and why cant we use structures in a routine ? I mean, without
> passing it around, we should be able to use them in a
> routine, or am I missing something here ?
What I mean is, you can have them in the arguments in a routine...
structure test
integer i,j,k
end structure
procedure funky(test monkey)
test goober
goober.i = monkey.i
goober.j = monkey.j
goober.k = monkey.k
end procedure
will translate to:
procedure funky(integer monkey_i, monkey_j, monkey_k )
integer goober_i, goober_j, goober_k
goober_i = monkey_i
goober_j = monkey_j
goober_k = monkey_k
end procedure
The local variable goober is ok, but the variable monkey will cause
problems. I would have to up the intelligence of the processor to handle
those kinds of variables.
> Anyways... nice work.
Thanks
> Ralf
_______ ______ _______ ______
[ _ \[ _ ][ _ _ ][ _ ]
[/| [_] |[/| [_\][/ | | \][/| [_\]
| ___/ | _] | | | _]
[\| [/] [\| [_/] [\| |/] [\| [_/]
[_____] [______] [_____] [______]
xseal at harborside.com ICQ:13466657
http://www.harborside.com/home/x/xseal/euphoria/
|
Not Categorized, Please Help
|
|