1. A rather dreamy request...
- Posted by Hawke <mdeland at NWINFO.NET>
Aug 18, 1998
-
Last edited Aug 19, 1998
okay, I was in that realm of non-sleeping sleep...
that half-dreaming-wide-awake mode we all have happen
to us just before going unconcious..ya know?
there is a feature that I would like to see added
to euphoria, or any of its variants. (not sure
if it could actually be done with preProc...)
Certain algorithms, and more importantly (to me)
win32 programming could become far easier to implement
and execute.
Here goes:
In euphoria, you have three data types: atoms, sequences,
and objects. A sequence can be either a collection
of atoms, atoms & sequences, or sequences of sequences.
An object can be either an atom or sequence.
Nothing but the obvious so far..right? Onwards.
We have all been talking about OOP, dotnotations,
etc.etc.etc. blahblahblah ad nauseum...
What is the difference between Pascal/C and euph?
Data structures can contain procedure/function names.
It becomes the 'method', the way of calling a function
if an *element* is addressed. VB, VC++, and (hopefully)
VisEuph will be able to do things like MainWindow.OnFocus
or BartPicture.Load or btnOK.Click or sleFirstName.caption...
We see here the mixing of dotnotations addressing both
-variables- (.caption) or -functions- (.load).
Can euph do this? no. Would it take a major rewrite
to include this in Euph3.0? *yes*
My idea: we already -have- element addressing which works
the same way a dotnotation would in the first place, why
not use it? (watches a few 'huh?' pass by)
We can access any element of a sequence or object. What if
that element was a *function*? (note, I would only think
and want this to be used with 'object' data types, not
sequences...first I'll illustrate, then explain that)
=======begin pseudocode======
constant picfname = 1
constant caption = 2
constant helptip = 3
constant picclick = 4 --alternate picture for when pressed/clicked
constant font = 5
constant color = 6
constant sunken = 7
constant clicked = 8
object btnStartTimer --starts a stopwatch...fer ex.
btnStartTimer[picfname] = "start.bmp" --pretty picture of a watch?
btnStartTimer[caption] = "Start" --text on button face(over pic)
btnStartTimer[helptip] = "Press to start timing" --mouseover tip
btnStartTimer[picclick] = "startclk.bmp" --mebbe hands rotating?
btnStartTimer[font] = {TimesRoman,12}--font for btn face text
btnStartTimer[color] = {129,223,59} --RGB for font(trucolor??)
btnStartTimer[sunken] = FALSE --false is raised/etched
btnStartTimer[clicked] = --this is the idea...
====end pseudocode======
see, btnStartTimer[clicked] would somehow be a *function*...
(or procedure...i use the word function generically here)
first I was thinking that we could simply assign it like:
btnStartTimer[clicked] = routineID("btnStartTimer_Clicked")
and have the function:
procedure btnStartTimer_Clicked()
btnEndTimer[Enable] = TRUE --let the end button be ungrayed
lblStartTimer[caption] = time() --display the starttime
lblEndTimer[caption] = "" --clear the endtime label
end procedure
but there is a problem with that assignment...
with euph as it stands, you can't *execute* an element.
you cannot say:
--splash the end game logo
if baddies = 0 then picWonGame[show] end if
because picWonGame[show] won't *do* anything... it's waiting
for the other half of an assignment...
hopefully, I have presented this in a manner that anyone
besided myself actually understands... :) I know, it seems
like a stream of conciousness posting... tried not to
make it that way :)
take care all-- Hawke'
2. Re: A rather dreamy request...
Hawke, what exactly is the difference with this approuch other than
syntaxtical ?
constant btnStartTimer[clicked] = routine_id ("btnStartTimerRoutine")
And then call it like:
call_proc (btnStartTimer[clicked])
The difference is, the routine could in your approuch not be called in a
normal sence.
So, your real suggestion is about the scope rules of routines.
Your point however stands, but I would appriciate to clearify how (IMHO) it
would make more sense and be more consistent:
1) Everything we can declare local or global can *now* also be declared
local to an variable or data type.
Now you wonder: can't we already do that with all other data types ? No, not
with constants: Im talking e-nummeration here.
So we could have a sequence, containing atoms, sequences, routines, and
constants.
? btnStartTimer[my_routine]
btnStartTimer[my_constant] = 4 -- Error: value is 'locked-in'
btnStartTimer = {1,2,2,2,2} -- This *is* allowed
Next to this consider ennumeration: a constant local to an atom can only be
used to assign or compare that atom with.
Do that same with routines: this atom can only be an argument for that
routine.
So, every datatype (sequence, onbject, atom) has their own list of constants
and routines.
What you people think about this idea ?
Lastly, ive got another request: (automatic constant assingment)
Some one asked for new elements to be appended if they are one over length.
What about this (more safe) approuch
sequence my_sequence
element pizza = 5
element radio = 3
element name = "Euphoria"
? my_sequence -- print {5,3,"Euphoria"}
element addres = "members.aol.com/FilesEU"
? my_sequence[radio] -- print 3
link other_sequence
element top = 230
link third_sequence[3] as short_name do
element music = "POP"
? short_name[music]
The link makes a sequence for use with the 'element' operator
And optionally you can add an 'as ..' to have an alias for a sequence:
link fourth_sequence[1][2][3][4][5] as index do
for a = 1 to 1230 do
? index * a
end for
-- Now I know it is optimized, but these kind of things make it look more
clear, make it easier for ex.exe to optimize and together with the 'element'
operator allow nice subscription.
Here my drain of thoughts stops, thanx for listening..
Ralf
3. Re: A rather dreamy request...
Hawke wrote:
...<snip>
> Here goes:
> In euphoria, you have three data types: atoms, sequences,
> and objects. A sequence can be either a collection
> of atoms, atoms & sequences, or sequences of sequences.
> An object can be either an atom or sequence.
> Nothing but the obvious so far..right? Onwards.
> We have all been talking about OOP, dotnotations,
> etc.etc.etc. blahblahblah ad nauseum...
> What is the difference between Pascal/C and euph?
> Data structures can contain procedure/function names.
> It becomes the 'method', the way of calling a function
> if an *element* is addressed.
....<snip>
The real difference? In C or Pascal, you can declare an element of a
structure to be: integer, string, func, proc, etc....
Euphoria doesn't allow that. There's the prob. You have:
a. lost the ability to type-check stuff going into a structured
variable, and
b. the program no longer has any way to tell what is legal to do with
that variable.
> btnStartTimer[color] = {129,223,59} --RGB for font(trucolor??)
> btnStartTimer[sunken] = FALSE --false is raised/etched
> btnStartTimer[clicked] = --this is the idea...
> ====end pseudocode======
>
> see, btnStartTimer[clicked] would somehow be a *function*...
Yes. and btnStartTimer[sunken] would be boolean. If there was a byte
stored with
that element of the structure, Euphoria could examine the byte and
decide how to
handle the request (either make an assignment or return a value) in the
same
manner it does now with:
x = 0
if x then ... -- where x is 1 or 0.
I don't know how difficult such a thing might be to add. But all the
discussion
on these subjects is leading the same way: simpler and more versatile
syntax.
Regards,
Irv
4. Re: A rather dreamy request...
Ralf Nieuwenhuijsen wrote:
> Hawke, what exactly is the difference with this approuch other than
> syntaxtical ?
> constant btnStartTimer[clicked] = routine_id ("btnStartTimerRoutine")
> And then call it like:
> call_proc (btnStartTimer[clicked])
actually, *blush*, I had forgotten about call_proc, or rather,
didn't think to implement it that way. your above code actually
does what i was suggesting.
things like:
if baddies = 0 then call_proc(picWonGame[load]) end if
(provided you had
constant picWonGame[load] = routine_id("picWonGame_Load")
already predefined)
would actually work... correct?
it's not quite as easy to read as dr.seuss but it's not
that bad either. I dunno, i guess i was just trying to
avoid all that 'messy' routine_id/call_proc coding...
the advantage of doing that i suppose, as compared to
simply:
if baddies=0 then picWonGame_Load end if
would be that it becomes "truly" global by using
routineID/callproc... right? and the benefit of
that "truly global" is to allow for better data
hiding and encapsulation (is that the right word?)??
of data and their associated routines?
and sooooo i humbly withdraw my dreamy request,
since it's already "done" anyway...
take care of another today-- Hawke'
5. Re: A rather dreamy request...
Irv wrote:
>The real difference? In C or Pascal, you can declare an
>element of a structure to be: integer, string, func, proc, etc....
>Euphoria doesn't allow that. There's the prob. You have:
>a. lost the ability to type-check stuff going into a structured
>variable, and
this i dont necessarily mind, as we have gained, finally!
thru sequences, true data/variable independence and freedom...
>b. the program no longer has any way to tell what is legal to do with
>that variable.
now this... different story. I'm not all that wild about it either.
price to pay for freedom? hrmmmmm...
>I don't know how difficult such a thing might be to add.
>But all the discussion on these subjects is leading the
>same way: simpler and more versatile syntax.
yes. gimme :) heh, gimme 7! one for each DOW...
--Hawke'
6. Re: A rather dreamy request...
It is possible to do this kind of thing in Euphoria 2.0 (or a more limited
version in an earlier version). Here is how I would implement it in
Euphoria 2.0:
All that needs to be done is to write a program that would convert
something like this:
class button
global string caption
global routine onclick
end class
button mybutton
mybutton.caption =3D "Testing..."
mybutton.onclick =3D routine_id("onclick")
to this:
constant BUTTON_CAPTION =3D 1
constant BUTTON_ONCLICK =3D 2
type routine(object o)
if integer(o) then
if o > -1 then
return 1
end if
end if
return 0
end type
type char(object o)
if integer(o) then
if o > -1 and o < 256 then
return 1
end if
end if
return 0
end type
type string(object o)
if sequence(o) then
for i =3D 1 to length(o) do
if char(o[i]) =3D 0 then
return 0
end if
end for
return 1
end if
return 0
end type
type button(sequence s)
if length(s) =3D 2 then
if string(s[1]) and routine(s[2]) then
return 1
end if
end if
return 0
end type
procedure onclick()
end procedure
button mybutton
mybutton =3D {"",0}
button[BUTTON_CAPTION] =3D "Testing..."
button[BUTTON_ONCLICK] =3D routine_id("onclick")
You could keep the flexability of Euphoria types (and add to it) by being
able to "implement" or "extend" other classes like in Java.
class Object
end class
class Integer extends Object
end class
class Atom extends Object
end class
class Sequence extends Object
end class
I think I could write a program to do this, but any
comments/suggestions/help would be appreciated.
