1. Eu improvements (Part 1)
- Posted by Karl Bochert <kbochert at copper.net> Jan 03, 2007
- 544 views
One of my biggest problems with Eu comes when I look at someone's code and see something like
if atom( base[2][4]) then ...
What is the significance of the 4th item of the kind of sequence put into the 'base' sequence? Does base contain different kinds of sequences, or a single kind? Does the nature of its contents change with time? Therefore:
sequence point is -- define a fixed sequence sequence name atom x, y end sequence ... point.x = 0 -- set point's x value if point.x > 0 then point.name = 3 -- illegal point = concat(point, 0) -- illegal mylist[1].name = "!!" -- can be in a seq. -- the above opaque example might now be: if atom(base[2].location) -- The location of base's second element -- or perhaps if atom(base.values[4]) -- The fourth vale of base
The 'fixed sequence': 1) has named elements 2) cannot have its structure modified 3) contains only data (like any other sequence) 4) may be put in another sequence without losing its identity (like any other data) KtB
2. Re: Eu improvements (Part 1)
- Posted by c.k.lester <euphoric at cklester.com> Jan 03, 2007
- 502 views
Karl Bochert wrote: > > The 'fixed sequence': > 1) has named elements > 2) cannot have its structure modified > 3) contains only data (like any other sequence) > 4) may be put in another sequence without losing its > identity (like any other data) That's a cool idea, Karl. It seems to take sequences to the next level. I guess you could then do sequence line is point x point y end sequence sequence shape is line a line b line c end sequence I suspect it won't be easy to implement, eh?
3. Re: Eu improvements (Part 1)
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 03, 2007
- 501 views
c.k.lester wrote: > > Karl Bochert wrote: > > > > The 'fixed sequence': > > 1) has named elements > > 2) cannot have its structure modified > > 3) contains only data (like any other sequence) > > 4) may be put in another sequence without losing its > > identity (like any other data) > > That's a cool idea, Karl. It seems to take sequences to the next level. > > I guess you could then do > > sequence line is > point x > point y > end sequence > > sequence shape is > line a > line b > line c > end sequence > > I suspect it won't be easy to implement, eh? Well, the ooeu equivalent is:
euclass point( sequence p ) atom x, y end euclass
euclass line( sequence l ) point p1, p2 end euclass
euclass shape( sequence s ) line a, b, c end euclass </euclass>
One of the demos that comes with ooeu is shape.ex, and shows some simple ways that you can build up objects from other objects. There is no enforcement of changing the structure in ooeu, however.
Matt }}}
4. Re: Eu improvements (Part 1)
- Posted by c.k.lester <euphoric at cklester.com> Jan 03, 2007
- 521 views
Matt Lewis wrote: > > Well, the ooeu equivalent is: Does ooeu perform comparably to standard ex(wcu).exe? Is it cross platform? If ooeu does everything ex... does, with just a little more overhead, then I might consider sending it to our testing workshop.
5. Re: Eu improvements (Part 1)
- Posted by Karl Bochert <kbochert at copper.net> Jan 03, 2007
- 509 views
c.k.lester wrote: > That's a cool idea, Karl. It seems to take sequences to the next level. > > I guess you could then do > > sequence line is > point x > point y > end sequence > > sequence shape is > line a > line b > line c > end sequence Shhh! you're giving away part II > > I suspect it won't be easy to implement, eh? Thats why we have Robert Craig! KtB
6. Re: Eu improvements (Part 1)
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 03, 2007
- 516 views
- Last edited Jan 04, 2007
c.k.lester wrote: > > Matt Lewis wrote: > > > > Well, the ooeu equivalent is: > > Does ooeu perform comparably to standard ex(wcu).exe? Is it cross platform? > If ooeu does everything ex... does, with just a little more overhead, > then I might consider sending it to our testing workshop. Most of the OOP stuff is completely front end related. It's probably a little slower to parse, but I doubt it would be easy to tell the difference (haven't done a lot of tests). There are several things that I have modified in the C-based backend that might cause slight slowdowns in certain cases. Overall, though, it should be very similar, since it's largely the same code. It's cross platform (although I don't do any DOS stuff, you could probably build it there if you really wanted to--same for BSD). The last release was before the open sourcing of eu, so that's all based on the euphoria implementation. I haven't gotten all the ooeu features working with the c-based backend yet. The eval() features are pretty much the only things I can think of off the top of my head--that's a much more complex implementation, because you have to re-bridge the frontend to backend gap (converting all the indices to pointers, etc). My approach is going to be to create linked lists of things like the SymTab and the __eval__ code blocks that will grow and change each time there's an eval. It's all up on svn at sourceforge (ooeu.sf.net), including makefiles for OpenWatcom and gcc. Matt
7. Re: Eu improvements (Part 1)
- Posted by James W Hofmann <jhofmann at ucsc.edu> Jan 03, 2007
- 523 views
- Last edited Jan 04, 2007
I had the same idea, but with a different syntax that fits into the type system:
type Foo(sequence s) index a = s[1] index b = s[2] index c = s[3] return 1 -- any type can be this type end type Foo f sequence bad bad = {10,20,{30,40}} f = bad ? f.a -- 10 ? bad.b -- fails, sequence has no index for "a" ? f.c[2] -- 40
The issue of "confusing indexes" is a reason for adding syntactic sugar; declaring a constant value can serve a lot of the same needs, but the scope is wrong(too wide). The type system can already enforce a regular structure on your data, it just needs to be extended to be useful beyond that. The big point of dispute, I think, is that doing it the specific way I've implemented makes types stronger, perhaps too strong; if you didn't declare the variable with "Foo" there's no way to implicitly restate as a Foo later. You will have to copy the data. An redesigned syntax, then, with that in mind:
Foo f sequence bad, good good = {10,20,{30,40,{50,60}} f = good ? f:Foo.a -- 10 ? good:Foo.b -- 20 ? good:Foo.c:Foo.a -- 30 ? good:Foo.c:Foo.c -- {50,60} ? good:Foo.c[3] -- {50,60} bad = {1,2} ? bad:Foo.c -- error; invalid subscript. Or error; typecheck failed.
This one makes the code verbose but extremely clear; the user reasserts that they are using the specified object as a particular type, for the purpose of a sequence indexing operation. You're more likely to skip typing things right now because that system is only good for tests; if types made the code more clear as well we would be using them for that benefit as well, and maybe that would encourage more testing. Also, this solution looks relatively easy to implement compared with a full class or struct type. It adds a second kind of type check to the existing one: when a dot-value is used the interpreter can go to a lookup hash for the calling type. If the hash doesn't mention the requested dot-value, the type-check has failed. If type-checking is disabled or the code is compiled to C, these values could be translated to constant values and there would be zero runtime performance loss(possibly a longer startup).
8. Re: Eu improvements (Part 1)
- Posted by Jason Gade <jaygade at yahoo.com> Jan 03, 2007
- 515 views
- Last edited Jan 04, 2007
This looks interesting, but I would like to see a more substantive example. What would be the effect of without typecheck? I kind of like the first example better but then use the colon notation as kind of a "cast". Maybe. Hmm. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
9. Re: Eu improvements (Part 1)
- Posted by James W Hofmann <jhofmann at ucsc.edu> Jan 04, 2007
- 518 views
Jason Gade wrote: > > This looks interesting, but I would like to see a more substantive example. > > What would be the effect of without typecheck? Original source
type Point(sequence s) index x=s[1] index y=s[2] return length(s)=2 end type Point p sequence q p={0,0} -- initialize q={5,5} for nx=1 to 10 do p.x = nx ? p.x p.y = p.x+1 ? p.y end for -- output is 1,2,2,3,3,4,4,5,5,6,6,7,7... ? q:Point.x -- output is 5
Typecheck off makes it into this equivalent:
sequence p sequence q p={0,0} -- initialize q={5,5} for nx=1 to 10 do p[1] = nx ? p[1] p[2] = p[2]+1 ? p[2] end for ? q[1] -- output is 5
At least, I think that's how it would look. A simple replacement of name-notation with number-notation. > I kind of like the first example better but then use the colon notation as > kind > of a "cast". Maybe. Hmm. Both notations could work, because they do different things. Dot-only(simple-dot?) notation says "use the type that you declared the variable as." Colon-dot notation says "try to use this particular type on this variable." In the above example I used simple-dot because it felt natural to me after doing it so often to reference class variables in Python. But having the other seems like a reasonable idea for code needing greater structure. I don't really have a good feel for the potential downsides, though.
10. Re: Eu improvements (Part 1)
- Posted by Jason Gade <jaygade at yahoo.com> Jan 04, 2007
- 507 views
This looks pretty cool. I do kind of like dot notation and I've been studying a bit of Javascript lately (which I like) so I'm not against dot notation. I'm trying to see for myself how well it would fit into Euphoria. I like the idea. If I understand correctly, though, that if you use "without typecheck" then you will be unable to use the dot notation, correct? That is what I got from your original post and from the post I'm replying to. I don't really have an opinion about that I'm just trying to be clear on that. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
11. Re: Eu improvements (Part 1)
- Posted by Chris Bensler <bensler at nt.net> Jan 04, 2007
- 502 views
Before we get carried away, please consider the ramifications of these proposals. I'd like to see something like structured sequences in Eu. I would also like to see some simple form of OOP (I haven't checked out Matt's OOEU, but it appears to be too complex/advanced for what I would like to see in Eu), but would it be a good idea to implement both? OO objects are just an advanced form of structured arrays (sequences) and can be used to implement a simple structure if you want. You cannot use a simple structure to implement a 'this' keyword or class hierarchy. Chris Bensler ~ The difference between ordinary and extraordinary is that little extra ~ http://empire.iwireweb.com - Empire for Euphoria
12. Re: Eu improvements (Part 1)
- Posted by James W Hofmann <jhofmann at ucsc.edu> Jan 04, 2007
- 502 views
Jason Gade wrote: > I like the idea. If I understand correctly, though, that if you use "without > typecheck" then you will be unable to use the dot notation, correct? That is > what I got from your original post and from the post I'm replying to. I don't > really have an opinion about that I'm just trying to be clear on that. That is incorrect; the second version shows the result of the interpreter processing the file at runtime. When typechecks are off all type-related statements "disappear" for the interpreter, so what I'm showing is what it might do to preserve the same meaning. he actual source is the same.
13. Re: Eu improvements (Part 1)
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 04, 2007
- 508 views
Chris Bensler wrote: > > Before we get carried away, please consider the ramifications of these > proposals. > > I'd like to see something like structured sequences in Eu. I would also like > to see some simple form of OOP (I haven't checked out Matt's OOEU, but it > appears > to be too complex/advanced for what I would like to see in Eu), but would it > be a good idea to implement both? OO objects are just an advanced form of > structured > arrays (sequences) and can be used to implement a simple structure if you > want. > You cannot use a simple structure to implement a 'this' keyword or class > hierarchy. I'm curious as to what appears to be more complex than what you wanted. Matt
14. Re: Eu improvements (Part 1)
- Posted by Jason Gade <jaygade at yahoo.com> Jan 04, 2007
- 499 views
Chris Bensler wrote: > > Before we get carried away, please consider the ramifications of these > proposals. > > I'd like to see something like structured sequences in Eu. I would also like > to see some simple form of OOP (I haven't checked out Matt's OOEU, but it > appears > to be too complex/advanced for what I would like to see in Eu), but would it > be a good idea to implement both? OO objects are just an advanced form of > structured > arrays (sequences) and can be used to implement a simple structure if you > want. > You cannot use a simple structure to implement a 'this' keyword or class > hierarchy. > > > Chris Bensler > ~ The difference between ordinary and extraordinary is that little extra ~ > <a href="http://empire.iwireweb.com">http://empire.iwireweb.com</a> - Empire > for Euphoria See, I don't really want fixed sequences or structures. However named members almost gets you to the same point. A large part of OO is just a more advanced form of structured sequences anyway. (Not all of it...) One thing I really like about Euphoria is it's genericity and relatively weak type-checking. Then there's the fact that the programmer can strengthen type-checking if he so chooses. That's why I'm so interested in James W. Hofmann's proposal--it seems to me more of an extension of Euphoria instead of some kind of Frankenstein's monster bolted together with pieces from other languages. Regarding OOEU--I've never really used the additional features but I absolutely love the trace facility that Matt added to it. That alone makes it worthwhile. I don't think there is anything particularly complicated about it. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
15. Re: Eu improvements (Part 1)
- Posted by Michael J. Sabal <m_sabal at yahoo.com> Jan 04, 2007
- 507 views
I've set up a poll at Yahoo Groups: http://tech.groups.yahoo.com/group/programming_euphoria/surveys?id=12494187 This survey will be open until January 18, and the results will determine the priority in the project queue. The ability to create structures has been discussed at length in this forum. To summarize VERY briefly, the benefits include code clarity and improved interfacing to external libraries. The cons include interpreter complexity and performance degradation. Other benefits can be found in the forum archives, but I would be interested in hearing from anyone who can think of any other negatives. The actual method of implementation will still need to be hashed out, and perhaps we can put up another poll when this one is done to address those issues. Michael Sabal
16. Re: Eu improvements (Part 1)
- Posted by Chris Bensler <bensler at nt.net> Jan 04, 2007
- 509 views
Matt Lewis wrote: > > I'm curious as to what appears to be more complex than what you wanted. Without having investigated it thouroughly, it's pretty much what I would expect, but I think it's taking too big of a step at once. Mostly, I don't think polymorphism belongs. I also think that inheritance should be limited to one parent. I would also reuse the global keyword to allow public and private members. Chris Bensler ~ The difference between ordinary and extraordinary is that little extra ~ http://empire.iwireweb.com - Empire for Euphoria
17. Re: Eu improvements (Part 1)
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 04, 2007
- 515 views
Chris Bensler wrote: > > Matt Lewis wrote: > > > > I'm curious as to what appears to be more complex than what you wanted. > > Without having investigated it thouroughly, it's pretty much what I would > expect, > but I think it's taking too big of a step at once. > Mostly, I don't think polymorphism belongs. Fair enough. > I also think that inheritance should be limited to one parent. That is the case in ooeu, unless you consider grandparents to be multiple parents:
euclass A( sequence A ) -- ... end euclass euclass B( A b ) -- ... end euclass euclass C( B c ) -- ... end euclass
> I would also reuse the global keyword to allow public and private members. That is my plan, as well. Matt