1. Homogeneous sequence
- Posted by Juergen Luethje <j.lue at ?mx.de> Aug 11, 2007
- 710 views
Hi all, I want to have a user-defined type, that checks whether a variable is a homogeneous sequence. With this, I mean a sequence which contains only top-level elements of the same "structure". I think I can't express it better in English, please see the following code for details. Did I overlook anything? Should an empty sequence be considered homogeneous? Any comments are welcome.
function object_structure (object x) if atom(x) then return 1 end if for i = 1 to length(x) do x[i] = object_structure(x[i]) end for return x end function global type homogeneous_sequence (object x) object struc if atom(x) then return 0 end if if length(x) = 0 then return 1 -- ? end if struc = object_structure(x[1]) for i = 2 to length(x) do if not equal(struc, object_structure(x[i])) then return 0 end if end for return 1 end type -- Demo: object a, b, c a = {3,{3 ,5,{5,2},4}} b = {4,{5 ,1,{9,2},4}} c = {4,{{},1,{9,2},4}} ? object_structure(a) ? object_structure(b) ? object_structure(c) ? homogeneous_sequence({a,b}) ? homogeneous_sequence({a,c}) ? homogeneous_sequence({b,c})
Regards, Juergen
2. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at g?x.?e> Aug 11, 2007
- 669 views
Me wrote: > Hi all, > > I want to have a user-defined type, that checks whether a variable is a > homogeneous sequence. With this, I mean a sequence which contains only > top-level elements of the same "structure". I think I can't express it > better in English, please see the following code for details. > Did I overlook anything? Should an empty sequence be considered > homogeneous? Any comments are welcome. > }}} <eucode> > function object_structure (object x) > if atom(x) then > return 1 > end if > > for i = 1 to length(x) do > x[i] = object_structure(x[i]) > end for > return x > end function I just realized, that the following code does the same:
function object_structure (object x) return x = x end function
> global type homogeneous_sequence (object x) > object struc > > if atom(x) then > return 0 > end if > > if length(x) = 0 then > return 1 -- ? > end if > > struc = object_structure(x[1]) > for i = 2 to length(x) do > if not equal(struc, object_structure(x[i])) then > return 0 > end if > end for > > return 1 > end type > > -- Demo: > object a, b, c > a = {3,{3 ,5,{5,2},4}} > b = {4,{5 ,1,{9,2},4}} > c = {4,{{},1,{9,2},4}} > > ? object_structure(a) > ? object_structure(b) > ? object_structure(c) > ? homogeneous_sequence({a,b}) > ? homogeneous_sequence({a,c}) > ? homogeneous_sequence({b,c}) > </eucode> {{{ > Regards, > Juergen
3. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at ?lueyonder.co.u?> Aug 11, 2007
- 681 views
Juergen Luethje wrote: > > Hi all, > > I want to have a user-defined type, that checks whether a variable is a > homogeneous sequence. With this, I mean a sequence which contains only > top-level elements of the same "structure". You realise this will fail if the table contains eg {name, salary} and the lengths of the names are not all the same? There is a potentially exponential performance hit type-checking every element of a sequence like this. If length(table) is 1000 then a table[5]=x statement will rigorously type-check the other 999 elements. A possible solution is:
-- homogenous.e sequence the_table -- local, so no-one else can play with it global type tableitem(sequence x) if length(x)=2 and sequence(x[1]) and atom(x[2]) then return 1 end if return 0 end type global procedure replace(integer idx, tableitem x) the_table[idx]=x end procedure global funtion get_item(integer idx) return the_table[idx] end function -- plus a host of similar functions to append, remove, insert etc
In other words the_table is not itself type-checked, but all the operations allowed on it are. I accept that the above, while solving a particular performance problem, is rather cumbersome and does not easily scale well to handle multiple tables. Regards, Pete
4. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at ?mx.?e> Aug 11, 2007
- 669 views
Pete Lomax wrote: > Juergen Luethje wrote: > > > Hi all, > > > > I want to have a user-defined type, that checks whether a variable is a > > homogeneous sequence. With this, I mean a sequence which contains only > > top-level elements of the same "structure". > You realise this will fail if the table contains eg {name, salary} and the > lengths > of the names are not all the same? > > There is a potentially exponential performance hit type-checking every element > of a sequence like this. If length(table) is 1000 then a table[5]=x statement > will rigorously type-check the other 999 elements. > A possible solution is: > > -- homogenous.e > sequence the_table -- local, so no-one else can play with it > > global type tableitem(sequence x) > if length(x)=2 and sequence(x[1]) and atom(x[2]) then > return 1 > end if > return 0 > end type > > global procedure replace(integer idx, tableitem x) > the_table[idx]=x > end procedure > > global funtion get_item(integer idx) > return the_table[idx] > end function > -- plus a host of similar functions to append, remove, insert etc > > In other words the_table is not itself type-checked, but all the operations > allowed on it are. I accept that the above, while solving a particular > performance > problem, is rather cumbersome and does not easily scale well to handle > multiple > tables. Thanks for the reply, Pete. I don't understand how it answers my question, though. My origininal post probably was not very clear. Here is the reason why I'm interested in all this: A global library function shall operate on all elements of a list which is passed to it as parameter. I'm not talking of tables, but the list could contain _any_ type of elements, as long as all elements in the list have the same "structure". I want the function to do Euphoria sequence operations with all elements of the list like this:
function foo (homogenous_sequence list) sequence z, list ... z = list[1] for i = 2 to length(list) do z += list[i] end for ... end function
I want the elements of 'list' to be either all atoms or all sequences. If all elements of 'list' are sequences, then their lengths must be the same, ozherwise Eu sequence ops won't work. If the sequences contain sub-sequences, their length must also be the same, I think. So I'm looking for a good way to implement the user-defined type 'homogenous_sequence', that checks whether either all elements of 'list' are atoms, or all elements of 'list' are sequences with the same lengths, and with the same order of atoms and sequences inside, and all corresponding sub-sequences also must have the same lengths and so on ... Regards, Juergen
5. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at ?gricul?ure.gouv.fr> Aug 11, 2007
- 664 views
- Last edited Aug 12, 2007
Juergen Luethje wrote: > > Pete Lomax wrote: > > > Juergen Luethje wrote: > > > > > Hi all, > > > > > > I want to have a user-defined type, that checks whether a variable is a > > > homogeneous sequence. With this, I mean a sequence which contains only > > > top-level elements of the same "structure". > > You realise this will fail if the table contains eg {name, salary} and the > > lengths > > of the names are not all the same? > > > > There is a potentially exponential performance hit type-checking every > > element > > of a sequence like this. If length(table) is 1000 then a table[5]=x > > statement > > will rigorously type-check the other 999 elements. > > A possible solution is: > > > > -- homogenous.e > > sequence the_table -- local, so no-one else can play with it > > > > global type tableitem(sequence x) > > if length(x)=2 and sequence(x[1]) and atom(x[2]) then > > return 1 > > end if > > return 0 > > end type > > > > global procedure replace(integer idx, tableitem x) > > the_table[idx]=x > > end procedure > > > > global funtion get_item(integer idx) > > return the_table[idx] > > end function > > -- plus a host of similar functions to append, remove, insert etc > > > > In other words the_table is not itself type-checked, but all the operations > > allowed on it are. I accept that the above, while solving a particular > > performance > > problem, is rather cumbersome and does not easily scale well to handle > > multiple > > tables. > > Thanks for the reply, Pete. I don't understand how it answers my > question, though. My origininal post probably was not very clear. > Here is the reason why I'm interested in all this: > > A global library function shall operate on all elements of a list > which is passed to it as parameter. I'm not talking of tables, but the > list could contain _any_ type of elements, as long as all elements in > the list have the same "structure". > > I want the function to do Euphoria sequence operations with all elements > of the list like this: > }}} <eucode> > function foo (homogenous_sequence list) > sequence z, list > ... > z = list[1] > for i = 2 to length(list) do > z += list[i] > end for > ... > end function > </eucode> {{{ > I want the elements of 'list' to be either all atoms or all sequences. > If all elements of 'list' are sequences, then their lengths must be the > same, ozherwise Eu sequence ops won't work. If the sequences contain > sub-sequences, their length must also be the same, I think. > > So I'm looking for a good way to implement the user-defined type > 'homogenous_sequence', that checks whether either all elements of > 'list' are atoms, or all elements of 'list' are sequences with the > same lengths, and with the same order of atoms and sequences inside, > and all corresponding sub-sequences also must have the same lengths > and so on ... > > Regards, > Juergen You are painfully aware that type checking has a O(N) complexity, where N is not the legth, but the number of all atoms in all your subsequences. Reguar type checking is probably very inefficient here. Where do you get the objects you are processing from? My first approach would be to have such objects come from "trusted" sources, where the creation process, being under your control, would guarantee the lengths being equal etc. faster than checking on an object as if you didn't know anything about it. If the objects come from data files you didn't control the creation, then... you have no choice indeed. Try to check each object once, so that you can considered ti as trusted later, avoiding any further check. CChris
6. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at gm??de> Aug 11, 2007
- 685 views
- Last edited Aug 12, 2007
CChris wrote: > Juergen Luethje wrote: > > > Pete Lomax wrote: > > > > > Juergen Luethje wrote: > > > > > > > Hi all, > > > > > > > > I want to have a user-defined type, that checks whether a variable is a > > > > homogeneous sequence. With this, I mean a sequence which contains only > > > > top-level elements of the same "structure". > > > You realise this will fail if the table contains eg {name, salary} and the > > > lengths > > > of the names are not all the same? > > > > > > There is a potentially exponential performance hit type-checking every > > > element > > > of a sequence like this. If length(table) is 1000 then a table[5]=x > > > statement > > > will rigorously type-check the other 999 elements. > > > A possible solution is: > > > > > > -- homogenous.e > > > sequence the_table -- local, so no-one else can play with it > > > > > > global type tableitem(sequence x) > > > if length(x)=2 and sequence(x[1]) and atom(x[2]) then > > > return 1 > > > end if > > > return 0 > > > end type > > > > > > global procedure replace(integer idx, tableitem x) > > > the_table[idx]=x > > > end procedure > > > > > > global funtion get_item(integer idx) > > > return the_table[idx] > > > end function > > > -- plus a host of similar functions to append, remove, insert etc > > > > > > In other words the_table is not itself type-checked, but all the > > > operations > > > allowed on it are. I accept that the above, while solving a particular > > > performance > > > problem, is rather cumbersome and does not easily scale well to handle > > > multiple > > > tables. > > > > Thanks for the reply, Pete. I don't understand how it answers my > > question, though. My origininal post probably was not very clear. > > Here is the reason why I'm interested in all this: > > > > A global library function shall operate on all elements of a list > > which is passed to it as parameter. I'm not talking of tables, but the > > list could contain _any_ type of elements, as long as all elements in > > the list have the same "structure". > > > > I want the function to do Euphoria sequence operations with all elements > > of the list like this: > > > > function foo (homogenous_sequence list) > > sequence z, list > > ... > > z = list[1] > > for i = 2 to length(list) do > > z += list[i] > > end for > > ... > > end function > > > > I want the elements of 'list' to be either all atoms or all sequences. > > If all elements of 'list' are sequences, then their lengths must be the > > same, ozherwise Eu sequence ops won't work. If the sequences contain > > sub-sequences, their length must also be the same, I think. > > > > So I'm looking for a good way to implement the user-defined type > > 'homogenous_sequence', that checks whether either all elements of > > 'list' are atoms, or all elements of 'list' are sequences with the > > same lengths, and with the same order of atoms and sequences inside, > > and all corresponding sub-sequences also must have the same lengths > > and so on ... > > > > Regards, > > Juergen > > You are painfully aware that type checking has a O(N) complexity, where N is > not the legth, but the number of all atoms in all your subsequences. Reguar > type checking is probably very inefficient here. O(N) complexity doesn't cause any pain for me. > Where do you get the objects you are processing from? My first approach would > be to have such objects come from "trusted" sources, where the creation > process, > being under your control, would guarantee the lengths being equal etc. faster > than checking on an object as if you didn't know anything about it. > If the objects come from data files you didn't control the creation, then... > you have no choice indeed. Try to check each object once, so that you can > considered > ti as trusted later, avoiding any further check. I want the user-defined type-checking for the parameter of a library function, which is to be published. So it's not under my control in which context people will use it, and from where they get their data. That's actually the reason why I think it's a good idea to perform type- checking on the parameter. Also, we should be aware that in a library type-checking is only an _offer_ to the user of the library. After debugging of the program, type-checking should be turned off anyway. Regards, Juergen
7. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at blu?yo?der.co.uk> Aug 12, 2007
- 665 views
Juergen Luethje wrote: > > If all elements of 'list' are sequences, then their lengths must be the > same, otherwise Eu sequence ops won't work. Ding! I see now. My gut says there is a *faster* way, danged if I can articulate it proper though. The core idea would be Tmatch(template,object) rather than build a template for every object. But then again you said you care not about performance. To answer the questions actually posed: An empty sequence should imo be considered homogenous. So too should an atom, in this context, which you have excluded. You may also (one day) be looking at sq_op(a,b) and likewise wanting to prove that both a and b have matching structures, not particularly hard just something to factor in at the get-go. Regards, Pete
8. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at ?mx.de> Aug 12, 2007
- 682 views
Pete Lomax wrote: > Juergen Luethje wrote: > > > If all elements of 'list' are sequences, then their lengths must be the > > same, otherwise Eu sequence ops won't work. > > Ding! I see now. > > My gut says there is a *faster* way, danged if I can articulate it proper > though. > The core idea would be Tmatch(template,object) rather than build a template > for every object. I think I understand the reason why. When already the beginning of an object does not match the beginning of the template, it's not necessary any more to "go through" that whole object in order to create a template of it. > But then again you said you care not about performance. Another misunderstanding. The suggestion "Do w/o type-checking, that will save time." just is not an option for me, since I want to do type- checking (i.e. offer it to the user of the library). But if there is a faster way to do it, then I'll be happy. Now I've written the following code, and will do some more tests with it:
function equal_structures_0 (object template, object x) -- out: TRUE/FALSE return equal(template, x=x) end function function equal_structures_1 (object x1, object x2) -- Here it is not necessary and also doesn't seem to be advantageous -- to create a template firstly. We can as well use the original data -- itself. -- out: TRUE/FALSE if atom(x1) and atom(x2) then return 1 end if if sequence(x1) and sequence(x2) and (length(x1) = length(x2)) then for i = 1 to length(x1) do if not equal_structures_1(x1[i], x2[i]) then return 0 end if end for return 1 end if return 0 end function -- Demo object a, b, c, template a = {3,{3 ,5,{5,2},4}} b = {4,{5 ,1,{9,2},4}} c = {4,{{},1,{9,2},4}} -- old way template = (a=a) ? equal_structures_0(template, b) ? equal_structures_0(template, c) -- new way ? equal_structures_1(a, b) ? equal_structures_1(a, c)
> To answer the questions actually posed: > An empty sequence should imo be considered homogenous. > So too should an atom, in this context, which you have excluded. > > You may also (one day) be looking at sq_op(a,b) and likewise wanting to prove > that both a and b have matching structures, not particularly hard just > something > to factor in at the get-go. That's a good idea, I think. Thanks, Juergen
9. Re: Homogeneous sequence
- Posted by Ricardo Forno <ricardoforno at tutop?a.c?m> Aug 12, 2007
- 671 views
Hi all. While reading this thread, I browsed my General Functions package and saw an obvious mistake in the example for the Structure function, which does a very similar thing to one of the functions discussed here. For now, I don't plan to post a correction, because the mistake is so obvious. Regards.
10. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at ?mx.d?> Aug 12, 2007
- 699 views
Ricardo Forno wrote: > Hi all. > While reading this thread, I browsed my General Functions package and saw > an obvious mistake in the example for the Structure function, which does > a very similar thing to one of the functions discussed here. > For now, I don't plan to post a correction, because the mistake is so > obvious. > Regards. Hello Ricardo, this reminds me ... When looking for the solution of a general problem, I actually should firstly look into your great General Functions package. Regards, Juergen
11. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at ?mx?de> Aug 12, 2007
- 668 views
Me wrote: <snip> > Now I've written the following code, and will do some more tests with it: > }}} <eucode> > function equal_structures_0 (object template, object x) > -- out: TRUE/FALSE > return equal(template, x=x) > end function > > function equal_structures_1 (object x1, object x2) > -- Here it is not necessary and also doesn't seem to be advantageous > -- to create a template firstly. We can as well use the original data > -- itself. > -- out: TRUE/FALSE > > if atom(x1) and atom(x2) then > return 1 > end if > > if sequence(x1) and sequence(x2) > and (length(x1) = length(x2)) then > for i = 1 to length(x1) do > if not equal_structures_1(x1[i], x2[i]) then > return 0 > end if > end for > return 1 > end if > > return 0 > end function > > -- Demo > object a, b, c, template > a = {3,{3 ,5,{5,2},4}} > b = {4,{5 ,1,{9,2},4}} > c = {4,{{},1,{9,2},4}} > > -- old way > template = (a=a) > ? equal_structures_0(template, b) > ? equal_structures_0(template, c) > > -- new way > ? equal_structures_1(a, b) > ? equal_structures_1(a, c) > </eucode> {{{ <snip> According to my tests, function 0 is clearly faster than function 1. Regards, Juergen
12. Re: Homogeneous sequence
- Posted by Bob Elia <bobelia200 at n?tzer?.net> Aug 12, 2007
- 691 views
Juergen Luethje wrote: > > Ricardo Forno wrote: > > > Hi all. > > While reading this thread, I browsed my General Functions package and saw > > an obvious mistake in the example for the Structure function, which does > > a very similar thing to one of the functions discussed here. > > For now, I don't plan to post a correction, because the mistake is so > > obvious. > > Regards. > > Hello Ricardo, > > this reminds me ... > When looking for the solution of a general problem, I actually should > firstly look into your great General Functions package. > > Regards, > Juergen Hi, Juergen This works, I think, though I'd rather have an iterative solution.
type seq_of_atom_or_empty(sequence s) if equal(s, {}) then return 1 end if for i = 1 to length(s) do if sequence(s[i]) then return 0 end if end for return 1 end type function object_structure_2(object x) if atom(x) then return 1 elsif seq_of_atom_or_empty(x) then return {} end if for i = 1 to length(x) do x[i] = object_structure_2(x[i]) end for return x end function global type homogeneous_sequence_2 (object x) object struc if atom(x) then return 0 end if if length(x) = 0 then return 1 -- ? end if struc = object_structure_2(x[1]) for i = 2 to length(x) do if not equal(struc, object_structure_2(x[i])) then return 0 end if end for return 1 end type -- Demo: object a, b, c a = {3,{3 ,5,{5,2},4}} b = {4,{5 ,1,{9,2},4}} c = {4,{{},1,{9,2},4}} -- ? object_structure(a) -- ? object_structure(b) -- ? object_structure(c) -- ? homogeneous_sequence({a,b}) -- ? homogeneous_sequence({a,c}) -- ? homogeneous_sequence({b,c}) ? object_structure_2(a) ? object_structure_2(b) ? object_structure_2(c) ? homogeneous_sequence_2({a,b}) ? homogeneous_sequence_2({a,c}) ? homogeneous_sequence_2({b,c})
Bob
13. Re: Homogeneous sequence
- Posted by c.k.lester <euphoric at ?kle?ter.com> Aug 12, 2007
- 670 views
object a, b, c, a1, b1, c1 a = {3,{3 ,5,{5,2},4}} b = {4,{5 ,1,{9,2},4}} c = {4,{{},1,{9,2},4}} a1 = a >= 0 or a < 0 b1 = b >= 0 or b < 0 c1 = c >= 0 or c < 0 ?equal(a1,b1) -- 1 ?equal(a1,c1) -- 0 ?equal(b1,c1) -- 0
14. Re: Homogeneous sequence
- Posted by c.k.lester <euphoric at cklester.?o?> Aug 12, 2007
- 673 views
- Last edited Aug 13, 2007
c.k.lester wrote: > > object a, b, c, a1, b1, c1 > a = {3,{3 ,5,{5,2},4}} > b = {4,{5 ,1,{9,2},4}} > c = {4,{{},1,{9,2},4}} > > a1 = a >= 0 or a < 0 > b1 = b >= 0 or b < 0 > c1 = c >= 0 or c < 0 Oops. I guess better (faster) is a1 = (a=a) b1 = (b=b) c1 = (c=c) > ?equal(a1,b1) -- 1 > ?equal(a1,c1) -- 0 > ?equal(b1,c1) -- 0
15. Re: Homogeneous sequence
- Posted by Bob Elia <bobelia200 at netzero.n??> Aug 12, 2007
- 666 views
- Last edited Aug 13, 2007
Bob Elia (me) wrote: > > Juergen Luethje wrote: > > > > Ricardo Forno wrote: > > > > > Hi all. > > > While reading this thread, I browsed my General Functions package and saw > > > an obvious mistake in the example for the Structure function, which does > > > a very similar thing to one of the functions discussed here. > > > For now, I don't plan to post a correction, because the mistake is so > > > obvious. > > > Regards. > > > > Hello Ricardo, > > > > this reminds me ... > > When looking for the solution of a general problem, I actually should > > firstly look into your great General Functions package. > > > > Regards, > > Juergen > > Hi, Juergen > > This works, I think, though I'd rather have an iterative solution. > > }}} <eucode> > type seq_of_atom_or_empty(sequence s) > if equal(s, {}) then > return 1 > end if > for i = 1 to length(s) do > if sequence(s[i]) then > return 0 > end if > end for > return 1 > end type > > function object_structure_2(object x) > if atom(x) then > return 1 > elsif seq_of_atom_or_empty(x) then > return {} > end if > > for i = 1 to length(x) do > x[i] = object_structure_2(x[i]) > end for > return x > end function > > global type homogeneous_sequence_2 (object x) > object struc > > if atom(x) then > return 0 > end if > > if length(x) = 0 then > return 1 -- ? > end if > > struc = object_structure_2(x[1]) > for i = 2 to length(x) do > if not equal(struc, object_structure_2(x[i])) then > return 0 > end if > end for > > return 1 > end type > > > -- Demo: > object a, b, c > a = {3,{3 ,5,{5,2},4}} > b = {4,{5 ,1,{9,2},4}} > c = {4,{{},1,{9,2},4}} > > -- ? object_structure(a) > -- ? object_structure(b) > -- ? object_structure(c) > -- ? homogeneous_sequence({a,b}) > -- ? homogeneous_sequence({a,c}) > -- ? homogeneous_sequence({b,c}) > ? object_structure_2(a) > ? object_structure_2(b) > ? object_structure_2(c) > ? homogeneous_sequence_2({a,b}) > ? homogeneous_sequence_2({a,c}) > ? homogeneous_sequence_2({b,c}) > > </eucode> {{{ > > Bob Nope, that doesn't work. I was trying to account for strings of un-equal length but {65,66,67} might not be one. Oops. In what form is the user providing this data? As Euphoria objects? Or are you converting it? Bob
16. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at gmx.??> Aug 12, 2007
- 692 views
- Last edited Aug 13, 2007
Bob Elia wrote: <big snip> > Nope, that doesn't work. I was trying to account for strings of un-equal > length but {65,66,67} might not be one. Oops. > > In what form is the user providing this data? As Euphoria objects? As a sequence. > Or are you converting it? I only want to create a user-defined type that checks the data which are passed as parameter to a library function. The definition of that type will be in the same library as the function, and it should look somehow like this:
global type homogeneous_sequence (object x) -- A sequence is considered homogeneous, when all its top-level -- elements have the same structure. We'll get the structure of an -- Euphoria object simply by assigning an arbitrary value (always the -- same, though!) to all of its atoms. Here the number 1 is used. object struc, t if atom(x) then return 0 end if if length(x) = 0 then return 1 end if t = x[1] struc = (t=t) -- assign 1 to all atoms in t for i = 2 to length(x) do t = x[i] if not equal(struc, t=t) then return 0 end if end for return 1 end type
Sorry, I can't explain it better. However, I'm happy with this type as it is now. Of course, if you or someone else has a suggestion that makes it considerably faster ... Regards, Juergen
17. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at ?mx.?e> Aug 12, 2007
- 683 views
- Last edited Aug 13, 2007
c.k.lester wrote: > c.k.lester wrote: > > > > object a, b, c, a1, b1, c1 > > a = {3,{3 ,5,{5,2},4}} > > b = {4,{5 ,1,{9,2},4}} > > c = {4,{{},1,{9,2},4}} > > > > a1 = a >= 0 or a < 0 > > b1 = b >= 0 or b < 0 > > c1 = c >= 0 or c < 0 > > Oops. I guess better (faster) is > > a1 = (a=a) > b1 = (b=b) > c1 = (c=c) Yes, that's faster. And that's what I have used in my posts in this thread (except of the first one). > > ?equal(a1,b1) -- 1 > > ?equal(a1,c1) -- 0 > > ?equal(b1,c1) -- 0 Regards, Juergen
18. Re: Homogeneous sequence
- Posted by Robert Craig <rds at RapidEuph?ria.co?> Aug 12, 2007
- 665 views
- Last edited Aug 13, 2007
CChris wrote: > You are painfully aware that type checking has a O(N) complexity, where N is > not the legth, but the number of all atoms in all your subsequences. Reguar > type checking is probably very inefficient here. This reminds me of a proposed extension to the type system that various people, including myself, have thought about before. It would be intuitively clear, and somewhat useful, to allow type declarations such as:
sequence of integer x sequence of object x sequence of sequence x sequence of sequence of atom x sequence of my_user_defined_type x etc.
In many cases this would reduce the type-checking cost from O(n) to O(1), since the type-check could be limited to a single value, e.g. x[5] = expression would only have to test x[5], not all of x, as you would need today if you made your own user-defined type that loops over all of x to enforce that it only contain elements of say integer, or some other type. Stricter types would help to catch bugs earlier in the code, and document variables more precisely. Type information, such as this, could also in many cases help the Translator to produce slightly faster C code. I spent a lot of time thinking about this a few years ago. I didn't proceed with it because: * I was worried that since the existing user-defined type system is not used all that much, perhaps this enhancement to the type system would not be used much either. People might be content to just say: sequence x rather than the much wordier: sequence of integer x On the other hand, this enhancement might encourage much more use of user-defined types. * Newbies might be confused, and put off by all this, thinking it was somehow necessary to provide full and proper types for everything. * It seemed at the time to be a fair bit of work, and extra baggage added to the language, for just a small gain. * In many cases, the Translator deduces this information by examining all uses of a variable across the whole program. But perhaps we should reconsider this idea. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
19. Re: Homogeneous sequence
- Posted by Bernie Ryan <xotron at bluef?og?com> Aug 12, 2007
- 672 views
- Last edited Aug 13, 2007
Robert Craig wrote: > > CChris wrote: > > You are painfully aware that type checking has a O(N) complexity, where N is > > not the legth, but the number of all atoms in all your subsequences. Reguar > > type checking is probably very inefficient here. > > This reminds me of a proposed extension to the type system > that various people, including myself, have thought about before. > It would be intuitively clear, and somewhat useful, to allow > type declarations such as: > }}} <eucode> > sequence of integer x > sequence of object x > sequence of sequence x > sequence of sequence of atom x > sequence of my_user_defined_type x > etc. > </eucode> {{{ > > In many cases this would reduce the type-checking cost from > O(n) to O(1), since the type-check could be limited to a > single value, e.g. > > x[5] = expression > > would only have to test x[5], not all of x, as you would need > today if you made your own user-defined type that loops over > all of x to enforce that it only contain elements of say > integer, or some other type. > > Stricter types would help to catch bugs earlier in the code, > and document variables more precisely. > > Type information, such as this, could also in many cases > help the Translator to produce slightly faster C code. > > I spent a lot of time thinking about this a few years ago. > I didn't proceed with it because: > > * I was worried that since the existing user-defined type > system is not used all that much, perhaps this enhancement > to the type system would not be used much either. People > might be content to just say: > sequence x > rather than the much wordier: > sequence of integer x > On the other hand, this enhancement might encourage much more > use of user-defined types. > > * Newbies might be confused, and put off by all this, > thinking it was somehow necessary to provide full and proper > types for everything. > > * It seemed at the time to be a fair bit of work, and extra > baggage added to the language, for just a small gain. > > * In many cases, the Translator deduces this information by > examining all uses of a variable across the whole program. > > But perhaps we should reconsider this idea. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> This would save typing: seq_of_int x seq_of_obj x seq_of_seq x seq_of_seq_of atom x seq_of_udt x Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
20. Re: Homogeneous sequence
- Posted by Derek Parnell <ddparnell at bi?pond.co?> Aug 13, 2007
- 681 views
Robert Craig wrote: > This reminds me of a proposed extension to the type system > that various people, including myself, have thought about before. > It would be intuitively clear, and somewhat useful, to allow > type declarations such as: > }}} <eucode> > sequence of integer x > sequence of object x > sequence of sequence x > sequence of sequence of atom x > sequence of my_user_defined_type x > etc. > </eucode> {{{ > But perhaps we should reconsider this idea. Yes, yes, yes! -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
21. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at gmx.??> Aug 13, 2007
- 671 views
Robert Craig wrote: > CChris wrote: > > You are painfully aware that type checking has a O(N) complexity, where N is > > not the legth, but the number of all atoms in all your subsequences. Reguar > > type checking is probably very inefficient here. > > This reminds me of a proposed extension to the type system > that various people, including myself, have thought about before. > It would be intuitively clear, and somewhat useful, to allow > type declarations such as: > }}} <eucode> > sequence of integer x > sequence of object x > sequence of sequence x > sequence of sequence of atom x > sequence of my_user_defined_type x > etc. > </eucode> {{{ > > In many cases this would reduce the type-checking cost from > O(n) to O(1), since the type-check could be limited to a > single value, e.g. > > x[5] = expression > > would only have to test x[5], not all of x, as you would need > today if you made your own user-defined type that loops over > all of x to enforce that it only contain elements of say > integer, or some other type. > > Stricter types would help to catch bugs earlier in the code, > and document variables more precisely. I really like this suggestion. It would be a "natural" extension of Euphoria's current type system. > Type information, such as this, could also in many cases > help the Translator to produce slightly faster C code. > > I spent a lot of time thinking about this a few years ago. > I didn't proceed with it because: > > * I was worried that since the existing user-defined type > system is not used all that much, perhaps this enhancement > to the type system would not be used much either. People > might be content to just say: > sequence x > rather than the much wordier: > sequence of integer x > On the other hand, this enhancement might encourage much more > use of user-defined types. This is hard to predict IMHO. > * Newbies might be confused, and put off by all this, > thinking it was somehow necessary to provide full and proper > types for everything. This would be my main concern. However, I think it can be avoided by good documentation. The current Eu documentation IMHO is good or very good. If explanations concerning the extended type system will be written in the same clear and precise way, neither too short nor too long, then people should easily understand it. > * It seemed at the time to be a fair bit of work, and extra > baggage added to the language, for just a small gain. I don't have enough knowledge about Eu's internals, so I can't judge how "bad" that is. > * In many cases, the Translator deduces this information by > examining all uses of a variable across the whole program. Cool! Maybe it would be interesting to know, how many people translate their programs, and how many people prefer to bind their programs. For instance IIRC reverse-engeneering of bound programs is harder than reverse-engeneering of translated/compiled programs, right?. If so, then this might be a reason for people to prefer to bind their programs rather than translate/compile them. > But perhaps we should reconsider this idea. My personal vote is "yes" -- being not the one who'll have to do the work. Regards, Juergen
22. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agricu?tur?.gouv.fr> Aug 13, 2007
- 674 views
Robert Craig wrote: > > CChris wrote: > > You are painfully aware that type checking has a O(N) complexity, where N is > > not the legth, but the number of all atoms in all your subsequences. Reguar > > type checking is probably very inefficient here. > > This reminds me of a proposed extension to the type system > that various people, including myself, have thought about before. > It would be intuitively clear, and somewhat useful, to allow > type declarations such as: > }}} <eucode> > sequence of integer x > sequence of object x > sequence of sequence x > sequence of sequence of atom x > sequence of my_user_defined_type x > etc. > </eucode> {{{ > Definitely a welcome addition, if only because of > Stricter types would help to catch bugs earlier in the code, > and document variables more precisely. > which I can verify to hold almost every day I work on a program. <snip> > * Newbies might be confused, and put off by all this, > thinking it was somehow necessary to provide full and proper > types for everything. Are they put off, in C, by "int some_ints[]", which Eu translates as
sequence of integer some_ints
? Probably adding a shortcut notation like the one Bernie suggested would be a good idea. > > * It seemed at the time to be a fair bit of work, and extra > baggage added to the language, for just a small gain. > > * In many cases, the Translator deduces this information by > examining all uses of a variable across the whole program. > One of my (revolutionary) thoughts is: now that the Translator is no longer a special part of the Eu distribution, isn't it time to use its algorithm (one or two passes only) in the interpreter, so as to generate some optimised IL? For mrograms that run in a loop (ie most instructions are executed several times), the overhead of type inference would be offset by sharper IL. Perhaps a new "with type_detect" would be useful to turn this on or off, if the overhead may be significative. CChris > But perhaps we should reconsider this idea. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
23. Re: Homogeneous sequence
- Posted by Derek Parnell <ddparnell at bi?p?nd.com> Aug 13, 2007
- 705 views
CChris wrote: > > }}} <eucode> > > sequence of integer x > > sequence of object x > > sequence of sequence x > > sequence of sequence of atom x > > sequence of my_user_defined_type x > > etc. > > </eucode> {{{ > Probably adding a shortcut notation like the one Bernie > suggested would be a good idea. I would strenuously fight against that suggestion. I didn't comment on Bernie's original post because I thought that it was so obviously a mistaken idea that no one would support it. If one must have a shortened syntax (and I can see why some might like that), then keep it in the 'Euphoria' style and avoid abbreviations etc... As all of these are variations are sequences of some sort, and the common English term for a sequence is 'list', then maybe something along the lines of ... integer list x object list x sequence list x atom list list x my_user_defined_type list x This form avoids the need for 'plural' English ("list of integers"), avoids the preposition word "of", parses unambiguously, is extensible and you can even avoid making "list" a reserved word by employing a context-sensitive grammar. By the way, notice that "object list" is identical to today's "sequence" so some purists might be tempted to remove 'sequence' as a keyword ... <just kidding> -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
24. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agr?culture.gouv.?r> Aug 13, 2007
- 675 views
Derek Parnell wrote: > > CChris wrote: > > > }}} <eucode> > > > sequence of integer x > > > sequence of object x > > > sequence of sequence x > > > sequence of sequence of atom x > > > sequence of my_user_defined_type x > > > etc. > > > </eucode> {{{ > > > > Probably adding a shortcut notation like the one Bernie > > suggested would be a good idea. > > I would strenuously fight against that suggestion. I didn't comment on > Bernie's > original post because I thought that it was so obviously a mistaken idea that > no one would support it. > > If one must have a shortened syntax (and I can see why some might like that), > then keep it in the 'Euphoria' style and avoid abbreviations etc... > > As all of these are variations are sequences of some sort, and the common > English > term for a sequence is 'list', then maybe something along the lines of ... > > integer list x > object list x > sequence list x > atom list list x > my_user_defined_type list x > > This form avoids the need for 'plural' English ("list of integers"), avoids > the preposition word "of", parses unambiguously, is extensible and you can > even > avoid making "list" a reserved word by employing a context-sensitive grammar. > > By the way, notice that "object list" is identical to today's "sequence" so > some > purists might be tempted to remove 'sequence' as a keyword ... <just kidding> > > -- > Derek Parnell > Melbourne, Australia > Skype name: derek.j.parnell This one suits me fine too. CChris
25. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at g?x.d?> Aug 13, 2007
- 662 views
Derek Parnell wrote: > CChris wrote: > > > }}} <eucode> > > > sequence of integer x > > > sequence of object x > > > sequence of sequence x > > > sequence of sequence of atom x > > > sequence of my_user_defined_type x > > > etc. > > > </eucode> {{{ > > > > Probably adding a shortcut notation like the one Bernie > > suggested would be a good idea. > > I would strenuously fight against that suggestion. I didn't comment on > Bernie's > original post because I thought that it was so obviously a mistaken idea that > no one would support it. > > If one must have a shortened syntax (and I can see why some might like that), > then keep it in the 'Euphoria' style and avoid abbreviations etc... I agree. > As all of these are variations are sequences of some sort, and the common > English > term for a sequence is 'list', then maybe something along the lines of ... > > integer list x > object list x > sequence list x > atom list list x > my_user_defined_type list x > > This form avoids the need for 'plural' English ("list of integers"), In his suggestion above, Rob did not use the plural form. He wrote "sequence of integer x". Or don't you like that because it's not correct English grammar? > avoids > the preposition word "of", parses unambiguously, is extensible and you can > even > avoid making "list" a reserved word by employing a context-sensitive grammar. > > By the way, notice that "object list" is identical to today's "sequence" so > some > purists might be tempted to remove 'sequence' as a keyword ... <just kidding> What you proposed can also be done with the word "sequence", I think. So it wouldn't be necessary to introduce a new keyword: integer sequence x object sequence x sequence sequence x atom sequence sequence x my_user_defined_type sequence x However, I think for me personally Rob's suggestion is better readable. And I consider readability much more important than "fast writability". Regards, Juergen
26. Re: Homogeneous sequence
- Posted by Salix <salix at f?eemail?hu> Aug 13, 2007
- 682 views
> integer sequence x > object sequence x > sequence sequence x > atom sequence sequence x > my_user_defined_type sequence x
-- Which one would be correct? sequence sequence sx sequence sequence integer sy sx={"Tom","Bob","Mary","John"} sy={"Tom","Bob","Mary","John"}
Rgds, Salix
27. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at ?mx.?e> Aug 13, 2007
- 670 views
Salix wrote: > > integer sequence x > > object sequence x > > sequence sequence x > > atom sequence sequence x > > my_user_defined_type sequence x > > }}} <eucode> > -- Which one would be correct? > > sequence sequence sx > sequence sequence integer sy > > sx={"Tom","Bob","Mary","John"} > sy={"Tom","Bob","Mary","John"} > </eucode> {{{ Both would be correct, and so would be sequence sx, sy or object sx, sy or sequence sequence object sx, sy or sequence sequence atom sx, sy Hmm ... maybe too confusing for beginners after all? Regards, Juergen
28. Re: Homogeneous sequence
- Posted by Salix <salix at freemai?.?u> Aug 13, 2007
- 674 views
Juergen Luethje wrote: > > Salix wrote: > > > > integer sequence x > > > object sequence x > > > sequence sequence x > > > atom sequence sequence x > > > my_user_defined_type sequence x > > > > }}} <eucode> > > -- Which one would be correct? > > > > sequence sequence sx > > sequence sequence integer sy > > > > sx={"Tom","Bob","Mary","John"} > > sy={"Tom","Bob","Mary","John"} > > </eucode> {{{ > > Both would be correct, and so would be > sequence sx, sy > or > object sx, sy > or > sequence sequence object sx, sy > or > sequence sequence atom sx, sy > > Hmm ... maybe too confusing for beginners after all? > > Regards, > Juergen Yes. Very confusing IMHO. I do not support this idea. Regards, Salix
29. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at ?lueyo?der.co.uk> Aug 13, 2007
- 696 views
Robert Craig wrote: > > This reminds me of a proposed extension to the type system > that various people, including myself, have thought about before. > It would be intuitively clear, and somewhat useful, to allow > type declarations such as: > }}} <eucode> > sequence of integer x > sequence of object x > sequence of sequence x > sequence of sequence of atom x > sequence of my_user_defined_type x > etc. > </eucode> {{{ > When I last thought about this, I came to the conclusion that the above was wrong. Specifically,
sequence of sequence of atom z
has two problems: 1) minimal semantic meaning 2) no way to perform the manual type check, unless you plan to allow:
if sequence of sequence of atom(z) then
As far as my logic got, I figured the *ONLY* place an "of" should be valid is in a user defined type definition:
type set(sequence of atom s) return 1 end type type set_table(sequence of set st) return 1 end type
Limiting the number of times that "of" can be used to *ONE* should help solve both the problems mentioned above, and allow sensibly typed work vars when playing with individual elements of these things. While I somehow doubt this will gain much in the way of popular support, I remain convinced it is far superior while still achieving all the benefits you outlined. Also, "sequence of object" should imo be an outright compilation error. That is what "sequence" already is and I see no reason to either perform a squillion isObj() tests or permit the expression then optimise it away. > I spent a lot of time thinking about this a few years ago. Did you leave any design notes lying around? > * Newbies might be confused, and put off by all this, > thinking it was somehow necessary to provide full and proper > types for everything. Maybe not. It has been a while now, but on re-reading: "To augment the predefined types, you can create user-defined types." "For many programs, there is little advantage in defining new types" "However, for larger programs, strict type definitions can aid debugging" I probably mentally skipped that section on first reading anyway, but was glad to know it was there. It is usually a good idea to drum up the doc changes first of all, and I feel sure you can find the words to reassure the newbie that they can keep it simple. Regards, Pete
30. Re: Homogeneous sequence
- Posted by Bernie Ryan <xotron at blu?fro?.com> Aug 13, 2007
- 672 views
Derek Parnell wrote: > As all of these are variations are sequences of some sort, and the common > English > term for a sequence is 'list', then maybe something along the lines of ... > > integer list x > object list x > sequence list x > atom list list x > my_user_defined_type list x > Derek: Aren't we simply saying: array of integer x array of object x array of sequence x array of array of sequence x array of my_user_defined_type x Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
31. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agricu?t?re.gouv.fr> Aug 13, 2007
- 666 views
Pete Lomax wrote: > > Robert Craig wrote: > > > > This reminds me of a proposed extension to the type system > > that various people, including myself, have thought about before. > > It would be intuitively clear, and somewhat useful, to allow > > type declarations such as: > > }}} <eucode> > > sequence of integer x > > sequence of object x > > sequence of sequence x > > sequence of sequence of atom x > > sequence of my_user_defined_type x > > etc. > > </eucode> {{{ > > > When I last thought about this, I came to the conclusion that the above was > wrong. Specifically, > }}} <eucode> > sequence of sequence of atom z > </eucode> {{{ > has two problems: > 1) minimal semantic meaning Your comment has minimal semantic meaning. > 2) no way to perform the manual type check, unless you plan to allow: > }}} <eucode> > if sequence of sequence of atom(z) then > </eucode> {{{ > As far as my logic got, I figured the *ONLY* place an "of" should be valid > is in a user defined type definition: > }}} <eucode> > type set(sequence of atom s) > return 1 > end type > type set_table(sequence of set st) > return 1 > end type > </eucode> {{{ > Limiting the number of times that "of" can be used to *ONE* should help solve > both the problems mentioned above, and allow sensibly typed work vars when > playing > with individual elements of these things. > I must be having a nightmare. So you never had to deal with sequences of strings, which would translate to
sequence of sequence of printable
? assuming printable is a subtype of atom, presumably checking for range 32..255 unless some UTF-16/32 encodings are to be accounted for. As the very frequent case above shows, the number should be raised to two at the very, very minimum. And giving any explicit limit is a kludge barely squaring with the otherwise dynamic nature of structures in Eu - there is no limit to the depth of a sequence. The docs may warn against too high a level for obvious performance reasons, but that should be all. Otherwise, I'd say that limiting the use of "of" to UDT declarations makes sense. > While I somehow doubt this will gain much in the way of popular support, I > remain > convinced it is far superior while still achieving all the benefits you > outlined. > > Also, "sequence of object" should imo be an outright compilation error. > That is what "sequence" already is and I see no reason to either perform a > squillion > isObj() tests or permit the expression then optimise it away. Optimize away the expression first, then perform the tests. Why raising an error? > > > I spent a lot of time thinking about this a few years ago. > Did you leave any design notes lying around? > > > * Newbies might be confused, and put off by all this, > > thinking it was somehow necessary to provide full and proper > > types for everything. > Maybe not. It has been a while now, but on re-reading: > "To augment the predefined types, you can create user-defined types." > "For many programs, there is little advantage in defining new types" > "However, for larger programs, strict type definitions can aid debugging" > > I probably mentally skipped that section on first reading anyway, but was glad > to know it was there. > > It is usually a good idea to drum up the doc changes first of all, and I feel > sure you can find the words to reassure the newbie that they can keep it > simple. > > Regards, > Pete Do we have any database of sorts of what newbies like, don't like or barely grasp? I have read this sort of comment repeatedly, while failing to see any objective evidence backing the opinions stated on behalf of the newbies by non newbies. Which makes those opinions rather dubious. CChris
32. Re: Homogeneous sequence
- Posted by Robert Craig <rds at RapidEupho?ia.co?> Aug 13, 2007
- 667 views
Derek Parnell wrote: > CChris wrote: > > Probably adding a shortcut notation like the one Bernie > > suggested would be a good idea. > > I would strenuously fight against that suggestion. I didn't comment on > Bernie's > original post because I thought that it was so obviously a mistaken idea that > no one would support it. > > If one must have a shortened syntax (and I can see why some might like that), > then keep it in the 'Euphoria' style and avoid abbreviations etc... I would not like Bernie's suggestion either. There would be an infinite number of different short forms required. If things were getting too wordy, I was thinking people could define for themselves some simple short forms (for example):
type string(sequence of integer s) return TRUE end type string name, country, province type matrix(sequence of sequence of atom m) return TRUE end type matrix chess_board
If you wanted tighter checking for strings you could write:
type char(integer x) return x >= 0 and x <= 255 end type type string(sequence of char s) return TRUE end type string name ... name[6] = 2.5
The above would only require that we check name[6] to see if 2.5 is a "char" or not (it's not). This is only O(1), so it would not kill your performance like O(n) would. Of course you could still say "without type_check" once your program was debugged. Note: if someone wrote, as you can today,
type string(sequence of integer s) for i = 1 to length(s) do if s[i] < 0 or s[i] > 255 then return FALSE end if end for return TRUE end type
the interpreter would have to run through the O(n) loop each time as it does now, when type_check is in force. It would be too much of a stretch for it to optimize that form. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
33. Re: Homogeneous sequence
- Posted by Robert Craig <rds at Rapi?Euphoria.c?m> Aug 13, 2007
- 665 views
Robert Craig wrote: > Note: if someone wrote, as you can today, > }}} <eucode> > type string(sequence of integer s) > for i = 1 to length(s) do > if s[i] < 0 or s[i] > 255 then > return FALSE > end if > end for > return TRUE > end type > </eucode> {{{ Of course, you can't exactly write that today, but I think you get the idea. The for-loop requires execution, even if only one element is changed, but if you break it down into a sequence of a user-defined type, then only that user-defined type needs to be executed, when an element of a sequence is modified. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
34. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at bl?eyonder.co.?k> Aug 13, 2007
- 677 views
CChris wrote: > > > }}} <eucode> > > type set(sequence of atom s) > > return 1 > > end type > > type set_table(sequence of set st) > > return 1 > > end type > > </eucode> {{{ > > Limiting the number of times that "of" can be used to *ONE* > > I must be having a nightmare. > So you never had to deal with sequences of strings You are misreading me. I am saying "force the programmer to give each level a plausible name". You can daisy-chain 37 udts together if you wish. In the above, a set_table is a sequence, each element of which is a set, where a set is a sequence, each element of which is an atom. For your example you could code:
type char(integer c) return c>=32 and c<=255 end type type line(sequence of char l) return 1 end type type file(sequence of line f) return 1 end type
As Salix pointed out "sequence of sequence of integer" simply does not hold a candle to the code readability of a "name_table" type definition. Obviously I accept the above is alot more typing .. and alot nicer. There are also some technical points I missed.
set_table k k[5]=z
If z is already type set, then you would not need to call set() as a result of this assignment. You can compare an explict type definition instantly, while you would still have to walk down the type-chain as each "[" is processed, it is obviously simpler than judging that "7 sequence of plus integer plus 3 subscripts" matches a replacement element of "4 sequence of plus integer". Because you are only changing k[5], then in the type set_table() definition, you do not need to type check the parameter st, but can invoke the udt after the leading TYPE_CHECK_SOF opcode (or do nothing if that would just be a return 1 as shown). In this way, a smart compiler and sensibly written code will often avoid launching a daisy chain of types, and hopefully optimise away any of the "return 1" bodies without much trouble. If it can do that last trick, I see no reason why it would be any slower than a hidden/inline implementation, and it will be easier to write sensible compiler-friendly code. > > Also, "sequence of object" should imo be an outright compilation error. > > That is what "sequence" already is and I see no reason to either perform a > > squillion > > isObj() tests or permit the expression then optimise it away. > > Optimize away the expression first, then perform the tests. Why raising an > error? Because it is redundant and potentially misleading. Why allow it? Regards, Pete
35. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agricu?tu?e.gouv.fr> Aug 13, 2007
- 695 views
Pete Lomax wrote: > > CChris wrote: > > > > > }}} <eucode> > > > type set(sequence of atom s) > > > return 1 > > > end type > > > type set_table(sequence of set st) > > > return 1 > > > end type > > > </eucode> {{{ > > > Limiting the number of times that "of" can be used to *ONE* > > > > I must be having a nightmare. > > So you never had to deal with sequences of strings > You are misreading me. I am saying "force the programmer to give each level > a plausible name". You can daisy-chain 37 udts together if you wish. > > In the above, a set_table is a sequence, each element of which is a set, where > a set is a sequence, each element of which is an atom. For your example you > could code: > }}} <eucode> > type char(integer c) > return c>=32 and c<=255 > end type > type line(sequence of char l) > return 1 > end type > type file(sequence of line f) > return 1 > end type > </eucode> {{{ > > As Salix pointed out "sequence of sequence of integer" simply does not hold > a candle to the code readability of a "name_table" type definition. > Obviously I accept the above is alot more typing .. and alot nicer. > > There are also some technical points I missed. > }}} <eucode> > set_table k > k[5]=z > </eucode> {{{ > If z is already type set, then you would not need to call set() as a result > of this assignment. You can compare an explict type definition instantly, > while > you would still have to walk down the type-chain as each "[" is processed, it > is obviously simpler than judging that "7 sequence of plus integer plus 3 > subscripts" > matches a replacement element of "4 sequence of plus integer". > > Because you are only changing k[5], then in the type set_table() definition, > you do not need to type check the parameter st, but can invoke the udt after > the leading TYPE_CHECK_SOF opcode (or do nothing if that would just be a > return > 1 as shown). > > In this way, a smart compiler and sensibly written code will often avoid > launching > a daisy chain of types, and hopefully optimise away any of the "return 1" > bodies > without much trouble. If it can do that last trick, I see no reason why it > would > be any slower than a hidden/inline implementation, and it will be easier to > write sensible compiler-friendly code. > Is't it easier for the compiler to see the whole of the daisy chain, and optimise as you said, if the type is presented as a whole? Otherwise, the compiler has to reassemble a few nested type declarations into the whole thing. More work both for coder and compiler, with nil benefits and perhaps a slight loss of performance. > > > Also, "sequence of object" should imo be an outright compilation error. > > > That is what "sequence" already is and I see no reason to either perform a > > > squillion > > > isObj() tests or permit the expression then optimise it away. > > > > Optimize away the expression first, then perform the tests. Why raising an > > error? > Because it is redundant and potentially misleading. Why allow it? > Because of the overhead of testing for it, because there is no example of such limitations in Eu, because it doesn't hurt since the last "object" will be simply ignored. I remember your writing "exceptions simply beget exceptions". That would be the short answer. CChris > Regards, > Pete
36. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at gmx.?e> Aug 13, 2007
- 678 views
Robert Craig wrote: <snip> > If you wanted tighter checking for strings you could write: > > type char(integer x) > return x >= 0 and x <= 255 > end type > > type string(sequence of char s) > return TRUE > end type </snip> Currently, there is a problem with code like that. When we e.g. write
.... if char(foo) then ...
then the program will crash instead of returning FALSE, in case 'foo' is not an integer. In order to avoid that, currently we have to define the type somehow like this:
type char(object x) return integer(x) and x >= 0 and x <= 255 end type
What would that problem mean regarding the proposed extension of the type system? Or maybe this behaviour can be changed, when the type system is revised? I'd appreciate that. And what do you think about Pete's proposal: | As far as my logic got, I figured the *ONLY* place an "of" should be | valid is in a user defined type definition: | | type set(sequence of atom s) | return 1 | end type | type set_table(sequence of set st) | return 1 | end type Curious, Juergen
37. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at bluey?nder.co.u?> Aug 13, 2007
- 672 views
- Last edited Aug 14, 2007
CChris wrote: > > Is't it easier for the compiler to see the whole of the daisy chain, and > optimise as you said, if the type is presented as a whole? Maybe. One of my nagging questions is this:
type ssm(sequence of sequence of myudt q) return 1 end type ssm k object z k[5]=z
After the assignment, where exactly do you type-check s[5]? If the programmer was forced to create a type sm and use that in the definition of type ssm, the answer would be obvious. Without it, well you are going to need a new typecheck opcode that contains a for loop anyway, but then that would have to become nested/recursive. At the end of the day it may be six of one and half a dozen of the other, but the lack of a named type to declare z with, and the corresponding extra type checks which will therefore need to be issued, swings it for me. > Otherwise, the compiler has to reassemble a few nested type declarations More a question of walking down an existing chain, I think. This stuff already works so I thought of piggybacking onto it:
type positive_int(integer pi) return pi>=0 end type type minute(positive_int m) return m<=59 end type type even_min(minute em) return and_bits(em,1)=0 end type type odd_min(minute om) return and_bits(om,1) end type odd_min z
> Because of the overhead of testing for it, because there is no example of > such limitations in Eu Ah, but is there any similar precedent of such redundancy in Eu? Anyway, it is just my [unshakeable] opinion it should error out. Regards, Pete
38. Re: Homogeneous sequence
- Posted by Derek Parnell <ddparnell at b?gpond.co?> Aug 13, 2007
- 676 views
- Last edited Aug 14, 2007
Bernie Ryan wrote: > > Derek Parnell wrote: > > As all of these are variations are sequences of some sort, and the common > > English > > term for a sequence is 'list', then maybe something along the lines of ... > > > > integer list x > > object list x > > sequence list x > > atom list list x > > my_user_defined_type list x > > > > Derek: > > Aren't we simply saying: > > array of integer x > array of object x > array of sequence x > array of array of sequence x > array of my_user_defined_type x Yes. The operative word being "simply". Most English speaking people, especially non-programmers, use the term "list" rather than "array" or "sequence" when describing such a structure. I feel that "list" is a simple, one-syllable, commonly used word. Also the form "<adjective> <noun>" is simpiler than the form "<noun> of <noun>", IMHO. Try reading out source code over the telephone. I agree that people who would write long definitions using this syntax should be gentle taken aside and educated. So maybe its also time to borrow another idea from the D programming language - alias. alias atom list text alias text list file file options These lines above mean that "text" is an alias for "atom list", and "file" is an alias for "text list", and we are declaring a symbol called "options" is is of type "file" which is really "text list" which is really "atom list list". The alias can be thought of as a light-weight UDT. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
39. Re: Homogeneous sequence
- Posted by Jason Gade <jaygade at ya?oo?com> Aug 13, 2007
- 672 views
- Last edited Aug 14, 2007
Reading this thread with interest and yet with reservations also. According to the proposal would I be able to do something like this:
sequence of integer x sequence y object z -- some code assigning values to x, y, and z x = y -- typecheck y to make sure it complies with the definition x = z -- ditto
Or would it fail right away because the type definitions do not match? -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
40. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at blue?onder.co.?k> Aug 14, 2007
- 686 views
Juergen Luethje wrote: > the program will crash instead of returning FALSE, in case 'foo' is > not an integer. In order to avoid that, currently we have to define the > type somehow like this: > }}} <eucode> > type char(object x) > return integer(x) and x >= 0 and x <= 255 > end type > </eucode> {{{ > What would that problem mean regarding the proposed extension of the type > system? Or maybe this behaviour can be changed, when the type system is > revised? I'd appreciate that. Good point. My proposal is useless without that change, I forgot that. I suspect this is a relatively easy change to try: Instead of emitting a TYPE_CHECK opcode at the top of a type definition, emit new opcodes which effect a return 0: Somewhere in parser.e you should find:
if SymTab[p][S_TOKEN] = TYPE and param_num != 1 then CompileErr("types must have exactly one parameter") end if
which seems the point to set a flag (change "and" to "then flag=1 if"), then after
-- code to perform type checks on all the parameters sym = SymTab[p][S_NEXT] for i = 1 to SymTab[p][S_NUM_ARGS] do TypeCheck(sym) sym = SymTab[sym][S_NEXT] end for
clear that flag. Within TypeCheck(), instead of
emit_op(INTEGER_CHECK) emit_op(SEQUENCE_CHECK) emit_op(ATOM_CHECK) emit_op(TYPE_CHECK)
when this flag is set emit some new opcodes which instead of (in execute.e):
procedure opINTEGER_CHECK() a = Code[pc+1] if not integer(val[a]) then RTFatalType(pc+1) end if pc += 2 end procedure
do a hacked version of opRETURNP/F() (instead of RTFatal) to return 0. At that point, it got a bit too messy for a quick hack to carry on with right now, but if you get the gist give it a twirl. Obviously I am only suggesting an experiment on eu.ex/hll back-end, in pure Eu code, also obviously you cannot test the flag in opINTEGER_CHECK(), but need the new opcodes and new routines. An interesting point would be whether you can find *ANY* working program that this change breaks, obviously I somewhat doubt it. > And what do you think about Pete's proposal: And what do you think about Pete's proposal? Regards, Pete
41. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at b?ue?onder.co.uk> Aug 14, 2007
- 671 views
Derek Parnell wrote: > > Try reading out source code over the telephone. > <snip> > > alias atom list text > alias text list file > file options > LOL! That tickled me, thanks! Obviously you're a fan of D unlike me and on closer reading it has merits but that specific syntax is not an Eu fit, imo. Still giggling, Pete
42. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at ?luey?nder.co.uk> Aug 14, 2007
- 672 views
Jason Gade wrote: > > Reading this thread with interest and yet with reservations also. > > According to the proposal would I be able to do something like this: > }}} <eucode> > sequence of integer x > sequence y > object z > > -- some code assigning values to x, y, and z > > x = y -- typecheck y to make sure it complies with the definition > x = z -- ditto > </eucode> {{{ > > Or would it fail right away because the type definitions do not match? I am sure you fears are unfounded. First, the typecheck both times is on x to ensure the new value fits. (error: type check failure, x is -1) Type checking is always done after the effect, for such messages. It is no different to y=z, failing (only) when z is not a sequence. The objective is to perform less type checks, not more. y=x would perform no typecheck whatsoever, because the compiler has enough type info to know it will succeed, ditto z=y and z=x. More detailed type info === even less checks. Actually this point is debateable: currently more detailed checks are so expensive no-one does them; if we slash the cost then argubly more people will use them, which is also an objective. Type-wise, you should note that the compiler can seem thick as pigshit:
integer i i=3.5 i="fred"
compiles/binds/translates without hitch. It only goes wrong at run-time; it is only the backend that knows much about type errors. Obviously the front-end is actually pretty smart about emitting the right code for the right types, just not about predicting type errors. Reasonable, I guess. HTH, Pete
43. Re: Homogeneous sequence
- Posted by Salix <salix at freemai?.h?> Aug 14, 2007
- 676 views
> > And what do you think about Pete's proposal: > And what do you think about Pete's proposal? I'm strongly against introducing these new definitions in general. (And not only Pete's suggestion.) For me Euphoria's motto is "just say NO to complicated programming languages". This change doesn't solves any of my coding problems but adds complexity to the syntax. I feel that this proposal is clearly against the "Clean and simple syntax", the "Minimal and simple to use Data Types", and probably the "Maintainability" points of the (non-official) mission statement (that I keep relevant). (See http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=ray+smith&keywords=Clean+and+simple+Syntax ) I think it is also against Rob's indirectly stated wish that Euphoria "will gain more users". (See http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=craig&keywords=birds ). Imagine a newbie asking how to define a simple "string" in Euphoria, that is a widely known and commonly used variable type?
list integer gain_for_salix -- or list atom gain_for_salix -- or list object gain_for_salix -- or sequence gain_for_salix -- or object gain_for_salix gain_for_salix="zero"
... a nightmare. Regards, Salix
44. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agri?ulture.go?v.fr> Aug 14, 2007
- 696 views
Pete Lomax wrote: > > Derek Parnell wrote: > > > > Try reading out source code over the telephone. > > > <snip> > > > > alias atom list text > > alias text list file > > file options > > > LOL! That tickled me, thanks! > > Obviously you're a fan of D unlike me and on closer reading it has merits but > that specific syntax is not an Eu fit, imo. > > Still giggling, > Pete Even more concise and visually intuitive:
{atom} s -- a sequence of atoms {{integer}} -- a sequence of sequences of integers {{}} -- a sequence of sequences
Since the interpreter expects type marks in very specific places, this construct is not ambiguous at all. And {atom}(s) could be parsed properly, including inside an if/while statement. öbject" in the middle would be optimised away easily, without any need to error out. How about that? CChris
45. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at ?gricu?ture.gouv.fr> Aug 14, 2007
- 667 views
Salix wrote: > > > > And what do you think about Pete's proposal: > > And what do you think about Pete's proposal? > > I'm strongly against introducing these new definitions in general. (And not > only Pete's suggestion.) > > For me Euphoria's motto is "just say NO to complicated programming languages". > This change doesn't solves any of my coding problems but adds complexity to > the syntax. > > I feel that this proposal is clearly against the "Clean and simple syntax", > the "Minimal and simple to use > Data Types", and probably the "Maintainability" points of the (non-official) > mission statement (that I keep > relevant). (See <a > href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=ray+smith&keywords=Clean+and+simple+Syntax">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=ray+smith&keywords=Clean+and+simple+Syntax</a> > ) > > I think it is also against Rob's indirectly stated wish that Euphoria "will > gain more users". (See <a > href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=craig&keywords=birds">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=craig&keywords=birds</a> > ). Imagine a newbie asking how to define a simple "string" in Euphoria, that > is a widely known and commonly > used variable type? > > }}} <eucode> > list integer gain_for_salix > -- or list atom gain_for_salix > -- or list object gain_for_salix > -- or sequence gain_for_salix > -- or object gain_for_salix > gain_for_salix="zero" > </eucode> {{{ > > ... a nightmare. > > Regards, > > Salix It will lose even more users if it doesn't gain some more power. A string is a sequence of printable. A printable is an integer, or a subrange of integers - it all depends of how strict you need to be. It is still ok to define a string as a sequence - that's what we all do - but no one here is happy to have {{1,2}} pass the type check. Are you? CChris
46. Re: Homogeneous sequence
- Posted by Igor Kachan <kinz at pe??rlink.ru> Aug 14, 2007
- 652 views
Salix wrote: > > > And what do you think about Pete's proposal: > > And what do you think about Pete's proposal? > > I'm strongly against introducing these new definitions in general. (And not > only Pete's suggestion.) Me too. I think it is not that important feature, anyone always can pack/unpack 8 bytes into atom or 4 bytes into integer, so "sequence of integer" or "sequence of atom" do not have great sense to me, nor "sequence of sequence". > For me Euphoria's motto is "just say NO to complicated programming languages". I think this slogan is something obsolete after opening of the source code of Euphoria. Anyway C, one of the most complicated languages, is involved for development of new Open Eophoria. We just can not say NO to C now, if we want new Euphoria. I'd like to see new slogan. Something like to "Euphoria! Just say YES to simple programming language!" > This change doesn't solves any of my coding problems but adds complexity to > the syntax. > > I feel that this proposal is clearly against the "Clean and simple syntax", > the "Minimal and simple to use > Data Types", and probably the "Maintainability" points of the (non-official) > mission statement (that I keep > relevant). (See <a > href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=ray+smith&keywords=Clean+and+simple+Syntax">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=ray+smith&keywords=Clean+and+simple+Syntax</a> > ) > > I think it is also against Rob's indirectly stated wish that Euphoria "will > gain more users". (See <a > href="http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=craig&keywords=birds">http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=craig&keywords=birds</a> > ). Imagine a newbie asking how to define a simple "string" in Euphoria, that > is a widely known and commonly > used variable type? > > }}} <eucode> > list integer gain_for_salix > -- or list atom gain_for_salix > -- or list object gain_for_salix > -- or sequence gain_for_salix > -- or object gain_for_salix > gain_for_salix="zero" > </eucode> {{{ > > ... a nightmare. I'm agreed, Salix, with your opinion. Regards, Igor Kachan kinz at peterlink.ru
47. Re: Homogeneous sequence
- Posted by Salix <salix at ?reemail?hu> Aug 14, 2007
- 654 views
CChris wrote: > Salix wrote: > It will lose even more users if it doesn't gain some more power. > A string is a sequence of printable. > A printable is an integer, or a subrange of integers - it all depends of how > strict you need to be. > It is still ok to define a string as a sequence - that's what we all do - but > no one here is happy to have {{1,2}} pass the type check. Are you? > Thanks for asking, CChris! I am. See, I don't think that Euphoria would gain a lot of power with this. I don't consider this issue critical from the leavers point of view. Talking about the "string" type, please make no mistake. I do not propose its implementation. If I need it I just define a new "type" or "function" to help me controlling the sequences in my programme. This also answers your question: yes, I am. That's what a sequence means for me. And whenever I want to check if {{1,2}} is a "sequence with a list of integers inside" then I do not check it with the "sequence()" function. It will obviously pass that type check. I use rather my unique "is_it_a_sequence_with_a_list_of_integers_inside()" function. I understand that adding a whole list of functions like that to the core language might mean a bit of speed. But regularly checking various objects is not typical in my opinion. (Surely not in my case.) And please note that introducing the change you are discussing affects heavily the syntax and readability of Euphoria. Regards, Salix
48. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at blue?onder.?o.uk> Aug 14, 2007
- 661 views
Salix wrote: > > > And what do you think about Pete's proposal? > > I'm strongly against introducing these new definitions in general. (And not > only Pete's suggestion.) > That's OK, but let me try rephrasing the question one last time.
sequence change_forced_on_salix change_forced_on_salix="zero"
Suppose there is a new string.e standard include (see Rob's post), then
include string.e string question, clause, person clause = "Would this help " person = "Salix" question = append(clause,person)
line 5: type check failure, question is {W,o,u,l,d, ,t,h,i,s, ,h,e,l,p, ,"Salix"} Immediately you know that & should have been used instead of append. Caused a few headaches with path & filename in edita.edb, and not much fun to clean up the mess such a bug makes, I can tell you. Putting this aside for a moment, would you like to see a new builtin string type in Eu? Regards, Pete
49. Re: Homogeneous sequence
- Posted by Salix <salix at fre??ail.hu> Aug 14, 2007
- 680 views
Pete Lomax wrote: > Putting this aside for a moment, would you like to see a new builtin string > type in Eu? Khm... I should admit that I skipped Rob's message on the "string(sequence of integer s)" solution. It makes most of my arguements on simple syntax of general coding not applicable. As you probably assumed I also have my debugging routines to avoid the famous "sequence found inside character string" error message and to keep on testing the data put into my sequences. But I can handle it with the currently received crash messages and later I delete anyway the seq. check routines. So I say rather "no". (But this time very quitely.) :-] Regards, Salix (who will not drop Euphoria because of a homogeneous sequence)
50. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agricu?ture.g?uv.fr> Aug 14, 2007
- 671 views
Salix wrote: > > Pete Lomax wrote: > > Putting this aside for a moment, would you like to see a new builtin string > > type in Eu? > > Khm... I should admit that I skipped Rob's message on the > "string(sequence of integer s)" solution. It makes most of > my arguements on simple syntax of general coding not applicable. > > As you probably assumed I also have my debugging routines to avoid > the famous "sequence found inside character string" error message > and to keep on testing the data put into my sequences. But I can > handle it with the currently received crash messages and later > I delete anyway the seq. check routines. > > So I say rather "no". (But this time very quitely.) :-] > > Regards, > > Salix > (who will not drop Euphoria because of a homogeneous sequence) lol Me neither. But homogeneous sequences may be one of the xx (two digit number) small reasons that might decide me to do so some day because they will add up to too much. CChris
51. Re: Homogeneous sequence
- Posted by Jason Gade <jaygade at yah?o?com> Aug 14, 2007
- 673 views
CChris wrote: > > Pete Lomax wrote: > > > > Derek Parnell wrote: > > > > > > Try reading out source code over the telephone. > > > > > <snip> > > > > > > alias atom list text > > > alias text list file > > > file options > > > > > LOL! That tickled me, thanks! > > > > Obviously you're a fan of D unlike me and on closer reading it has merits > > but > > that specific syntax is not an Eu fit, imo. > > > > Still giggling, > > Pete > > Even more concise and visually intuitive: > }}} <eucode> > {atom} s -- a sequence of atoms > {{integer}} -- a sequence of sequences of integers > {{}} -- a sequence of sequences > </eucode> {{{ > Since the interpreter expects type marks in very specific places, this > construct > is not ambiguous at all. > And {atom}(s) could be parsed properly, including inside an if/while > statement. > > öbject" in the middle would be optimised away easily, without any need to > error > out. > > How about that? > > CChris "More visually intuitive"? That's a joke, right? Anyway, blech! If I wanted to program in a language like that then I would. I'm sure there are several of them out there. I'm still with some of the naysayers on the whole idea -- I still don't see much benefit to it. The only think that I can think of is verifying whether a sequence is single-level or multi-level with regards to passing strings. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
52. Re: Homogeneous sequence
- Posted by Jason Gade <jaygade at y?h?o.com> Aug 14, 2007
- 663 views
Pete Lomax wrote: > > Jason Gade wrote: > > > > Reading this thread with interest and yet with reservations also. > > > > According to the proposal would I be able to do something like this: > > }}} <eucode> > > sequence of integer x > > sequence y > > object z > > > > -- some code assigning values to x, y, and z > > > > x = y -- typecheck y to make sure it complies with the definition > > x = z -- ditto > > </eucode> {{{ > > > > Or would it fail right away because the type definitions do not match? > > I am sure you fears are unfounded. > > First, the typecheck both times is on x to ensure the new value fits. > (error: type check failure, x is -1) So if y is a sequence of integers except for y[$] which is 1.1, at what point is x checked for validity? Is it an O(N) operation or an O(1) operation? Doesn't Euphoria usually just copy the pointer internally? > Type checking is always done after the effect, for such messages. > It is no different to y=z, failing (only) when z is not a sequence. > > The objective is to perform less type checks, not more. y=x would perform no > typecheck whatsoever, because the compiler has enough type info to know it > will > succeed, ditto z=y and z=x. More detailed type info === even less checks. I agree with performing fewer typechecks. And with needing to perform fewer. > > Actually this point is debateable: currently more detailed checks are so > expensive > no-one does them; if we slash the cost then argubly more people will use them, > which is also an objective. > > Type-wise, you should note that the compiler can seem thick as pigshit: > }}} <eucode> > integer i > i=3.5 > i="fred" > </eucode> {{{ > compiles/binds/translates without hitch. It only goes wrong at run-time; it > is only the backend that knows much about type errors. Obviously the front-end > is actually pretty smart about emitting the right code for the right types, > just not about predicting type errors. Reasonable, I guess. > > HTH, > Pete IIRC, before Euphoria's front-end was re-written, Rob was pretty proud of the speed of the interpreter's front end. Plus the fact that it would continue converting code to IL and executing code at the same time. Checking for certain obvious type errors in the front end makes a lot sense, but I've already seen some people complain about the slowness of the front end. (I'm not one, BTW). Hmm. This is a tangent, but it would be interesting for the front end to use the tasking feature maybe to do some of this... Except the back end would have to be aware of it also. The Euphoria to C translator should definitely be doing those kinds of checks though. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
53. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at gmx?de> Aug 14, 2007
- 660 views
Pete Lomax wrote: > Juergen Luethje wrote: > > the program will crash instead of returning FALSE, in case 'foo' is > > not an integer. In order to avoid that, currently we have to define the > > type somehow like this: > > > > type char(object x) > > return integer(x) and x >= 0 and x <= 255 > > end type > > > > What would that problem mean regarding the proposed extension of the type > > system? Or maybe this behaviour can be changed, when the type system is > > revised? I'd appreciate that. > Good point. My proposal is useless without that change, I forgot that. > > I suspect this is a relatively easy change to try: Instead of emitting a > TYPE_CHECK > opcode at the top of a type definition, emit new opcodes which effect a return > 0: > Somewhere in parser.e you should find: > > if SymTab[p][S_TOKEN] = TYPE and param_num != 1 then > CompileErr("types must have exactly one parameter") > end if > > which seems the point to set a flag (change "and" to "then flag=1 if"), then > after > > -- code to perform type checks on all the parameters > sym = SymTab[p][S_NEXT] > for i = 1 to SymTab[p][S_NUM_ARGS] do > TypeCheck(sym) > sym = SymTab[sym][S_NEXT] > end for > > clear that flag. Within TypeCheck(), instead of > > emit_op(INTEGER_CHECK) > emit_op(SEQUENCE_CHECK) > emit_op(ATOM_CHECK) > emit_op(TYPE_CHECK) > > when this flag is set emit some new opcodes which instead of (in execute.e): > > procedure opINTEGER_CHECK() > a = Code[pc+1] > if not integer(val[a]) then > RTFatalType(pc+1) > end if > pc += 2 > end procedure > > do a hacked version of opRETURNP/F() (instead of RTFatal) to return 0. > > At that point, it got a bit too messy for a quick hack to carry on with right > now, but if you get the gist > give it a twirl. > > Obviously I am only suggesting an experiment on eu.ex/hll back-end, in pure > Eu code, also obviously you cannot test the flag in opINTEGER_CHECK(), but > need > the new opcodes and new routines. All this is a bit over my head. > An interesting point would be whether you can find *ANY* working program that > this change breaks, obviously I somewhat doubt it. > > > And what do you think about Pete's proposal: > And what do you think about Pete's proposal? My feeling says that it's really a good idea in order to avoid the clutter demonstrated by Salix. By I think I don't have sufficient knowledge to make a reasonable judgement. Regards, Juergen
54. Re: Homogeneous sequence
- Posted by Juergen Luethje <j.lue at g?x.d?> Aug 14, 2007
- 661 views
Salix wrote: > > > And what do you think about Pete's proposal: > > And what do you think about Pete's proposal? > > I'm strongly against introducing these new definitions in general. (And not > only Pete's suggestion.) > > For me Euphoria's motto is "just say NO to complicated programming languages". > This change doesn't solves any of my coding problems but adds complexity to > the syntax. Following Pete's suggestion, there will only be little additional complexity in the syntax. Maybe it will not solve any of your coding problems, but it will have some other advantages (see Rob's first post in this thread for details). > I feel that this proposal is clearly against the "Clean and simple syntax", > the "Minimal and simple to use > Data Types", and probably the "Maintainability" points of the (non-official) > mission statement (that I keep > relevant). (See > http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=ray+smith&keywords=Clean+and+simple+Syntax > ) Firstly, this "mission statement" is not only non-official, but it's very rather pretty much non-official. It's exactly nothing but a private post by a single Euphoria user. Secondly it's an error to believe that things are simpler when we have only very few datatypes. _There are_ different kinds of data in the world, and the better an Euphoria program can reflect them, the cleaner and safer it is. > I think it is also against Rob's indirectly stated wish that Euphoria "will > gain more users". (See > http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=8&fromYear=B&toMonth=A&toYear=B&postedBy=craig&keywords=birds > ). Imagine a newbie asking how to define a simple "string" in Euphoria, that > is a widely known and commonly > used variable type?
type char (integer x) return x >= 32 and x <= 127 -- or something similar end type type string (sequence of char) return TRUE end type
Where is the problem? > list integer gain_for_salix > -- or list atom gain_for_salix > -- or list object gain_for_salix > -- or sequence gain_for_salix > -- or object gain_for_salix > gain_for_salix="zero" > > > ... a nightmare. That's why Pete made the proposal to allow something like that only in the definition of types. So something like this will not be valid code. Regards, Juergen
55. Re: Homogeneous sequence
- Posted by Jason Gade <jaygade at yahoo?c?m> Aug 14, 2007
- 674 views
Juergen Luethje wrote: > > That's why Pete made the proposal to allow something like that only in > the definition of types. So something like this will not be valid code. > > Regards, > Juergen Huh. Somehow I totally missed that. http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=7&fromYear=C&toMonth=9&toYear=C&postedBy=Pete+Lomax&keywords=Homogeneous+sequence+*ONLY* Thanks for pointing that out, Juergen. Pete -- that allays some of my concerns. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
56. Re: Homogeneous sequence
- Posted by CChris <christian.cuvier at agri?ulture.gouv?fr> Aug 14, 2007
- 684 views
Jason Gade wrote: > > CChris wrote: > > > > Pete Lomax wrote: > > > > > > Derek Parnell wrote: > > > > > > > > Try reading out source code over the telephone. > > > > > > > <snip> > > > > > > > > alias atom list text > > > > alias text list file > > > > file options > > > > > > > LOL! That tickled me, thanks! > > > > > > Obviously you're a fan of D unlike me and on closer reading it has merits > > > but > > > that specific syntax is not an Eu fit, imo. > > > > > > Still giggling, > > > Pete > > > > Even more concise and visually intuitive: > > }}} <eucode> > > {atom} s -- a sequence of atoms > > {{integer}} -- a sequence of sequences of integers > > {{}} -- a sequence of sequences > > </eucode> {{{ > > Since the interpreter expects type marks in very specific places, this > > construct > > is not ambiguous at all. > > And {atom}(s) could be parsed properly, including inside an if/while > > statement. > > > > öbject" in the middle would be optimised away easily, without any need to > > error > > out. > > > > How about that? > > > > CChris > > "More visually intuitive"? That's a joke, right? > It is NOT a joke. Euphoria's verbosity is already pretty high, and code becomes rapidly hard to read with all those wordy stuff and long significative identifiers. Only proper spacing makes it tolerable, but then you bump rapidly into line length issues, since the display is not extensible. The idea is to fight visual clutter, the average level of which is dangerously high. Since we use {...} to denote a sequence of what's between the braces, it is pretty intuitive to put a type mark there instead of actual values to mean that the sequence is made of elements of such a type. But perhaps you don't like indicating sequence contents with braces? > Anyway, blech! If I wanted to program in a language like that then I would. > I'm sure there are several of them out there. > > I'm still with some of the naysayers on the whole idea -- I still don't see > much benefit to it. The only think that I can think of is verifying whether > a sequence is single-level or multi-level with regards to passing strings. > This is a frequent case, but by no means the only one: Is a string made of printable characters only? Are all the characters in some Unicode range, else change font? Are all records of the list the same length? (Juergen's initial concern) Do all records verify some consistency check, like s[i][DATE_START]<s[i][DATE_END] \forall i? And countless many other cases, which would be coded much more neatly than they now are. Of course, direct type checks are costly, but flagging homogeneous sequences would speed up a lot of things by allowing incremental type checking, as emphasized earlier in the thread. CChris > -- > A complex system that works is invariably found to have evolved from a simple > system that works. > --John Gall's 15th law of Systemantics. > > "Premature optimization is the root of all evil in programming." > --C.A.R. Hoare > > j.
57. Re: Homogeneous sequence
- Posted by Jason Gade <jaygade at yah?o?com> Aug 14, 2007
- 667 views
CChris wrote: > It is NOT a joke. Euphoria's verbosity is already pretty high, and code > becomes > rapidly hard to read with all those wordy stuff and long significative > identifiers. > Only proper spacing makes it tolerable, but then you bump rapidly into line > length issues, since the display is not extensible. The idea is to fight > visual > clutter, the average level of which is dangerously high. Obviously we disagree on that as well. I think that Euphoria's verbosity is "just right". Neither too long nor too short. I find it to be very readable. > > Since we use {...} to denote a sequence of what's between the braces, it is > pretty intuitive to put a type mark there instead of actual values to mean > that > the sequence is made of elements of such a type. > > But perhaps you don't like indicating sequence contents with braces? Yeah, on the RHS. Not the LHS. I find your example above practically unreadable. > > This is a frequent case, but by no means the only one: > Is a string made of printable characters only? > Are all the characters in some Unicode range, else change font? > Are all records of the list the same length? (Juergen's initial concern) > Do all records verify some consistency check, like > s[i][DATE_START]<s[i][DATE_END] > \forall i? > > And countless many other cases, which would be coded much more neatly than > they > now are. Of course, direct type checks are costly, but flagging homogeneous > sequences would speed up a lot of things by allowing incremental type > checking, > as emphasized earlier in the thread. > > CChris Then write a function or a type to do it! It's not that hard. I think you focus too much on the performance issues. Are we all still running at 33MHz or what? Anyway, as I said elsewhere in the thread, I liked Pete's idea of limiting it to new type definitions. That may also increase the usage of a well-designed but under-used language feature. -- A complex system that works is invariably found to have evolved from a simple system that works. --John Gall's 15th law of Systemantics. "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
58. Re: Homogeneous sequence
- Posted by Pete Lomax <petelomax at b?uey?nder.co.uk> Aug 14, 2007
- 676 views
Jason Gade wrote: > > Pete Lomax wrote: > > > > Jason Gade wrote: > > > > > > }}} <eucode> > > > sequence of integer x > > > sequence y > > > > > > x = y > > > </eucode> {{{ > > > > > the typecheck is on x to ensure the new value fits. > > So if y is a sequence of integers except for y[$] which is 1.1, at what point > is x checked for validity? Is it an O(N) operation or an O(1) operation? After assignment. It will be an O(N) operation, remember this is a replacement for a type with a for loop in it, currently the only way to preform this amount of detailed type-checking. > > Doesn't Euphoria usually just copy the pointer internally? Yes, and it still will for the builtin types, or if the types of x and y are the same, plus additionally the typecheck after x[5]=i which is an O(N) operation at the moment (for type-checked variables) would reduce to O(1) if i is an atom or 0 if it is an integer. No-one is going to be forced to use this if they do not want to, and the impact on them should be so miniscule it cannot be measured. > > just not about predicting type errors. Reasonable, I guess. > Rob was pretty proud of the speed of the interpreter's front end. Correct, that is why I accept this as reasonable. Regards, Pete
59. Re: Homogeneous sequence
- Posted by Robert Craig <rds at Rapid?upho?ia.com> Aug 15, 2007
- 679 views
Juergen Luethje wrote: > Robert Craig wrote: > <snip> > > > If you wanted tighter checking for strings you could write: > > > > type char(integer x) > > return x >= 0 and x <= 255 > > end type > > > > type string(sequence of char s) > > return TRUE > > end type > > </snip> > > Currently, there is a problem with code like that. When we e.g. write > }}} <eucode> > .... > if char(foo) then > ... > </eucode> {{{ > then the program will crash instead of returning FALSE, in case 'foo' is > not an integer. In order to avoid that, currently we have to define the > type somehow like this: > }}} <eucode> > type char(object x) > return integer(x) and x >= 0 and x <= 255 > end type > </eucode> {{{ > What would that problem mean regarding the proposed extension of the type > system? Or maybe this behaviour can be changed, when the type system is > revised? I'd appreciate that. As you suggest, perhaps when an argument with the incorrect type is passed to a type routine, the program should not die on the spot, but rather the type routine should simply return 0, indicating that the value does not belong to that type. This will allow the type routine to be used as a function, just to check yes or no, (1 or 0) whether a value belongs to that type. If the type routine is being called automatically by the interpreter at an assignment statement, or when arguments are passed to a normal *function*, then you will still get a type_check failure message (assuming "with type_check" is on), but the error traceback will start at the assignment statement, or function declaration line, not at the declaration line of the type routine, as happens now. I think this would be a somewhat better diagnostic message than what we get now. In Euphoria, a type routine is declared differently from a normal function, so I guess we could be excused in having slightly different rules in one versus the other. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com