Re: Pete: Your question
On Tue, 4 Nov 2003 19:56:24 +0000, Al Getz <Xaxo at aol.com> wrote:
>Hello again Pete,
Hi
>
>I do appreciate you looking at this. It's interesting
>and im sure you and others will find it useful if it
>makes it into the Euphoria interpreter (although it
>already is using the trick).
Al, *IF* you can convince me, you are probably about 10% of the way to
getting Rob to change EU ;-(
I am not against change, I just want proof that it is worthwhile.
>I believe you are over simplifying the 'generic' solution.
>Your constants 'input' and 'output' make it seem like these
>will be the only two constants ever needed, but that's not
>the case at all. Instead, they should be renamed to
>Instance1 and Instance2. This makes it a little more
>clear that if a third instance needs to be taken out,
>you'll have to go back into the test.e file and take
>out another constant 'Instance3', plus change the length
>of the sequence x to 3 instead of 2.
That's a case I need no argument for: usage specified in one file or
"include new" spread left right and centre.
> Not only that,
>these have to be global variables which adds to the
>global clutter of variables in the program.
>This is taken care of with the 'include new' approach,
>and also in the substitute code i presented, but not
>in your code. Your code doesnt automatically take
>care of this, so it cant be the same in five lines either.
"include new" will add more globals, all of the same name, so how you
can claim global clutter in your benefit astonishes me!
True, you *CAN* use some global constants to clarify the usage, but as
I said, you in no way have to.
>
>Also, your code doesnt automatically take care of
>which variable is used to access data, is it
>'input' or 'output'? Since you have to use a
>different variable name for each of these it increases
>the complexity of the code more still, and means the
>secondary include files have to be different too rather
>then exactly the same (for using the same include file).
If you, or anyone else, can show me an *actual use* I might get an
idea, but you can't, because there isn't one which is much better and
clearer using explicit references rather than implicit ones.
BTW: What, exactly, is the difference between:
test2:x=1
and
x[test2]=1
???
>
>Imagine a language where you only have one variable, x.
>You'd have to make it a sequence so you could store
>everything in it. It's true you could store everything
>in it one way or another, but it would REALLY be a pain
>in the A 
I wouldnt want to have to do that.
Don't remember suggesting that.
>
>Now imagine a language where you could define super
>variables, where you could make the variable anything
>you wanted it to be: sequence, atom, integer, or even
>a whole group of sequences atoms or integers, just
>by declaring this group.
Scary!
You didn't even imply this, but, yes, there is a serious flaw in the
way type checking works on elements of a sequence.
It sometimes does end up being too expensive to be useable, but that's
not specifically the argument here, and [TIP:] you haven't used that
argument yet 
.
>But that's not the end of it; because since it's a
>variable type, you can always declare it a second or more
>times.
Scary Squared!
integer x atom x object x sequence x mytype x
UH?
> If you delcare it in the same file you have to
>use a different name, but if it's delcared in a new file
>you can use the same name over again!
Why!??!??!?
That is clearly not what you want. What do you want?
>Such are the possibilities with something like
>'include new'. You get to declare a whole group of
>variables (all named according to a well defined plan)
>with a single line 'include new file.e as this'.
>Suddenly whatever object you defined in file.e is
>reusable without doing any extra work.
Rubbish. You must use test2:x instead of x[test2]
What is the [real] difference?
> Not only that,
>because the names of all the variables stay the same
>you are using the files variables in exactly the same
>way as you used the variables in the original file.
?Externally???
>This is quite a concept, although it isnt new of course.
New to me
>For example, a struct:
>
>--file.e
>global sequence rect
>rect={0,0,0,0}
>
>include new file.e as x
>include new file.e as y
>--now we have two structs to use exactly as defined in file.e
>x:rect={1,1,20,20}
>y:rect={10,10,100,100}
>
>Nice!
rect[x]={1,1,20,20}
rect[y]={10,10,100,100}
And nicer being?
>What's more, we can include the rect using the same variable if
>in two different include files:
>
>
>--fileA.e
>include new file.e as x
>x:rect=LoadRect()
>DoFileAStuff()
>
>--fileB.e
>include new file.e as x
>x:rect=LoadRect()
>DoFileBStuff()
>
Granted, but that just leads to confusion as far as I am concerned.
Why *deliberately* refer to two *different* x using the same name, no
clues, when you can make it obvious which you mean?
>In these two files, we use the 'rect' exactly
>the same way in both files, even using the same
>prefix x. If you understand how fileA works,
>you automatically understand how fileB works.
>
And that would differ from
rect[x]=blah blah blah
vs
rect[y]=blah blah blah
in exactly what "confusing" way?
>How does the code slow down when using sequences alone?
>
>In order to use plain sequences instead of include files
>to declare new sequences of the same nature, we have to
>increase the reference one more level:
>
>x:rect={1,2,3,4} y:rect={5,6,7,8}
>becomes:
>rect={{1,2,3,4},{5,6,7,8}}
Fair,
I'd say:
rect[x]={1,2,3,4}
rect[y]={5,6,7,8}
>which also means
>
>r=y:rect
>becomes:
>r=rect[2]
>
>So you see besides any fragmentation issues that might come up,
>we at least have to use one more index.
True
> If you read the web page
>about Euphoria speed issues you will find that the recommendation
>is to use as few references as possible when dealing with sequences,
>so that two levels are better then three, one better then two, and
>NONE is the best
True
>
>I think the main issue isnt about speed though.
Err... DOH!
> The main issue
>is to be able to declare an entirely new set of variables
>(and functions perhaps) with one line of code in the same way
>you take out a new local variable (say x) in another include
>file, perhaps even all with the same prefix name.
****WHY****??????
What is the actual use here?
Show me a proper, reasonable, sensible, worthwhile, useful example.
>The only way to reliably do this now is to rename the file
>and then include it a second time, but the you have to rename
>the file again to include it a third time, etc.
>It's not that bad i guess, but it would be fairly simple to
>change Euphoria to be able to include it a second or more
>times (esp since it works that way already as stated previously
>with the slashes).
But that is a *BUG* which someone else will want fixed for different
reasons. PLEASE not to rely on this, you'll hate yourself later.
>
>
>Perhaps the rewording of the 'includes' brings out the point:
Indeed, I think one of the best things Rob could do is "deprecate" the
"as" keyword, since it implies exactly what you are on about.
It really should have been "include" <file> "named" <name>
or somesuch. (It should continue to work, of course, just issue
warnings at the end of the file..)
>declare rect.e as r1
>declare rect.e as r2
>
>r1:rect={1,2,3,4}
>r1:ButtonPosition={10,10,80,20}
>r2:rect={5,6,7,8}
>r2:ButtonPosition={20,50,80,20}
>
>It's as if 'rect.e' is a type of variable in itself, which can
>be one or a set of variables.
>
>Another way of stating it:
>
>compare:
>
>atom x
>
>with:
>
>include new x.e as x
>
>In the first case, x is simply an atom.
>In the second case, x is a prefix for a whole set of variables of
>perhaps many basic types with suddenly with one single line come
>into existance for use by your program. One more line
>include new x.e as y
>and you have ANOTHER set of the same variables to use!
And this is difficult to keep track of, surely.
>It's basically like the idea of declaring a struct in C that
>has already been typedef'd.
LOL
But we *REALLY* don't have the syntax for that, and thank god not.
You cannot say, eg Device:Devmode:dmPointSize.
We all want this, like we want pointers and unchecked gotos
> You get to reuse the same names
>(although with a prefix of course) without having to copy and
>paste anything. The concept makes it look like a new type
>of variable that can be used almost like any other variable.
>It's very readable too.
Potentially very confusing too.
>
>
>Does any of this make this side of the debate a bit clearer now?
NO
Pete
|
Not Categorized, Please Help
|
|
