OpenEuphoria

2. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by irv mullins <irvm at ellijay.com> Sep 23, 2004
• 465 views

unknown wrote:
> 
> >> Can cause ambiguity.. although it is nice looking
> >> 
> >> what does a.b.2 mean? a[b][2] or a[b[2]] ?
> >> 
> W> a[b][2]
> W> however since you brought it up,
> W> a.b..2
> W> could mean
> W> a[b[2]]
> 
> a.b..2 can also mean a[b..2]
> 
> hehehe :D
> better use another syntax?

Here you see the reason subscripted sequences are not a substitute 
for real structures. Even though structures would make Euphoria 
code safer and clearer, Rob has shown little or no interest in 
implementing them. 

Irv

4. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by Hayden McKay <hmck1 at dodo.com.au> Sep 24, 2004
• 459 views

I have to vote against this. It only adds more complexity to an already
easily accessable sequence. Its just as easy to use;

constant a = 1, b = 2, c = 3
sequence array array = repeat(0, 3)
?array[a]
?array[b]
?array[c]

However it would be nice to be able to do this;

sequence array array = repeat(0, 10)
sequence slice sclice = array[5..2]

and maybee some enhanced type checking for valiables, eg;

type word(integer value) }}}

6. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 24, 2004
• 464 views

On Thu, 23 Sep 2004 15:29:40 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:

> unknown wrote:
(but I also reply to Derek below)
> > better use another syntax?

Trust me on this one...

The dot notation, if adopted, *MUST* be a simple shorthand for an
immediate subscript. (Highest possible precedence or whatever).

Eg
		 x.1+3
*Must* be
		x[1]+3
NOT
		x[1+3]

Before you proclaim that wrong, think about:

		x.balance+300


I care not about eg x.y.z, though would recommend it is always
x[y][z] rather than always x[y[z]] (basic left or right associativity
either way). You should not consider using this sort of shorthand for
slices, don't be silly.

<back to Derek's comments:>
>And slower. 
>
<snip>

Do you mean slower than eg

Constant PersonalName=1,
		FamilyName=2,
		...
type customer(sequence s)
	if length(s)!=5 then return 0 end if
	if not sequence(s[PersonalName]) then return 0 end if
	...
end type


>In which case, the interpreter would need to add extra checks to
>append(), prepend(), &, slicing and assignment to make sure it was
>not changing the target's length, or datatypes. 
Hmmm. You got me thinking about ways to make some of that illegal in
the eyes of the compiler...

I'm now thinking that CurrentCust&=<blah> is just a fatal
non-compilable meaningless statement.

I am also considering that while

		CurrentCust.PersonalName = "Derek"

is obviously valid,

	CCList=sequence of customer
	(If only we had "sequence of customer", ....)

		CCList[i].PersonalName = "Derek"

might not be valid/supported for a few versions to come, if it makes
things easier??

Not quite sure why I see that as critical, I suspect it is a
combination of the difficulty of implementig"sequence of"and the scope
problems of PersonalName, unless it can *only* be used as a short
immediate subscript on a customer var, which makes sense to me..

Whatever, I for one would certainly not attempt all of this in one
hit, related as it is or not! It is far from easy to see how best to
do it.

Regards,
Pete

8. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 24, 2004
• 473 views

On Thu, 23 Sep 2004 17:37:18 -0700, Hayden McKay
<guest at RapidEuphoria.com> wrote:

>However it would be nice to be able to do this;
>}}}
<eucode>
>sequence array array = repeat(0, 10)
>sequence slice sclice = array[5..2]
></eucode>
{{{

Why? what (typo aside) is slice? array[2..5]?

how about:
function ews(sequence s, integer fromidx, integer toidx)
-- either way slice:
	if fromidx>toidx then return s[toidx..fromidx] end if
	return s[fromidx..toidx]
end function
slice=ews(array,5,2)

>I had an idea for type checking constants.
>}}}
<eucode>
>type word(integer value)
>    return <= #FFFF
>end type
>constant VALUE = word(12345)
></eucode>
{{{

>
>I've decided against this one too because constants are allways static 
>but it might help for local variables eg;
>}}}
<eucode>
>integer value value = word(12345)
></eucode>
{{{


obviously you meant
word value value=12345

<BSG>

Regards,
Pete

10. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by Patrick Barnes <mrtrick at gmail.com> Sep 24, 2004
• 494 views

> Not quite sure why I see that as critical, I suspect it is a
> combination of the difficulty of implementig"sequence of"and the scope
> problems of PersonalName, unless it can *only* be used as a short
> immediate subscript on a customer var, which makes sense to me..

"difficulty of implementing "sequence of" "....

No! 
It's not difficult. 
If you check back through the list, I've put together lots of stuff on
"of", including a manifest (below), and a demo
(http://users.secsme.org.au/~prbarnes/misc/oth/of.zip)

It's very fast, much much faster than manually checking everything.

Rob said he didn't want to implement it because (paraphrasing, correct
me if I'm wrong Rob) type checking wasn't considered to be part of
euphoria, except for debugging, and any enhancements to it would
confuse newbies.

> Whatever, I for one would certainly not attempt all of this in one
> hit, related as it is or not! It is far from easy to see how best to
> do it.

Well, I believe we need a better type-checking system before we can
attempt to do any structures...
If the "of" system was implemented first, that would benefit many
people... even those not using structures. The structure system
couldn't be implemented on its own.


Y'know, it's wonderful that a sequence can hold anything... it's much
better than C-style arrays.
However, can *anyone* show me a program where they've used a sequence
variable that was:
1. Large.
2. Completely non-homogenous. That is, there was no underlying
structure to the sequence *at all*...

I find that I only have two kinds of sequences. 
Small ones - Holds something like a structure. non-homogenous, but
well-defined (ie first element is a XYpos, 2nd is a color, third is a
picture handle, etc.)

Big ones - Holds multiple small ones. Homogenous, because every
element has the same (small ones) structure.

I've never had to break from this. The "of" keyword could greatly
benefit me (yes, me me me) but I suspect many others too...

-- 
MrTrick




1.
The keyword 'of' is used in the Euphoria language to apply additional 
restrictions to a sequence. The 'of' declaration is ONLY allowed 
within a type declaration, in the form:

type $base_type ( sequence of $element_type )
    --###type body###--
end type

(? I figure this is a good idea, so that the typing is centralised ?)

2.
the left hand of the 'of' MUST be sequence. 

3.
There are no special restrictions on $element_type. It may be a 
pre-defined or a user-defined type.

4.
The allowable functionality within the ###type body### is restricted 
when the 'of' keyword is present in the header. (?Should we disallow 
access to external functions? Perhaps. ?)

4a.
The ###type body### should not access any of the elements, but only 
check aggregates of the base element, like length. (?If any element 
is accessed, a warning should be issued that the type may cause major
performance issues. This could be useful for a type that cares about
 the sum of it's elements?)

5.
$base_type and $element_type are not both incurred for every change. 
Refer to this table:

variable is assigned to another variable ( x = y ):
      * If y is of the same type, no checking is done.
	* If y has a different $base_type, but the same $element_type, check
only $base_type.
      * If y is of a completely different type, check $base_type, then check 
        $element_type against each element of the variable.

variable is assigned to a literal ( x = {3,5,1,7}):
      * If {}, only check $base_type.
      * Otherwise, check $base_type, then check $element_type against
        each element of the variable.

variable is assigned to a function return ( x = doStuff() ):
      * Behave according to the data type that was returned.

variable is assigned to the result of a logical operation 
                  ( x = {y[1]} & x[2..length(x) - 1] & {1} ):
      * First, check the $base_type
      * If a slice was taken from the same data type, then the elements
        are known to be valid. Do not check those elements.
      * If a component was not the same type or a literal, check the 
        elements in that type.
      
variable has an element or elements changed 
                  (x[1] = y[length(y)]    or   x[2..4] = {7,1,3}):
      * If the new value for the element already has the same data type,
        no checking is required.
      * If the new value has a different type or is a literal, check 
        that element(s).
      * (?As no changes would have occured to the aggregate properties 
        of the $base_type (length), don't check the base?)
      

Example:
type positive_int (integer t)
   return t >= 0
end type
type index ( sequence of positive_int s )
   return 1
end type

index x
x = {6}           -- checks base, and first element
x &= 4            -- checks base (cause length has changed) and new 
                  -- element, but not first
x[1] = 5          -- checks element 1, but not base (length has not 
                  -- changed)
x[1..2] = {4,1}   -- checks element 1 and 2
x &= {10, 0}      -- checks base, and the new elements, but not existing
x = y             -- If y is an index, no checking required, otherwise 
                  -- check whole sequence.
x = y[2..3] & {1} & y[5..length(y)] 
                  -- If y is an index, then no checking on that part of
                  -- the variable. Check base, and check the to-be-new 
                  -- elements that are not index elements already.
x = {0}           -- x is completely reassigned. If to a literal, check
                  -- the whole type.
x[1] = -1         -- error here (element 1 is checked, and fails.) 


6.
Some more optimisations can be made.
* If a type declaration does nothing (just returns 1) the interpreter will
  consider that type to be the same as that of its argument.
* Upon parsing, if multiple types (base or element) have the same profile
  (same arguments, same bytecode in ###type body###) they will be considered 
  to be the same type.

7.
Implementing these changes would probably need to be combined with 
making the regular types more robust - If an atom type is checked 
against a type that has a sequence or a sequence of %% argument, 
fail needs to be returned rather than crashing.

(?Perhaps also look at short-circuiting return values?)

8.
If a subscript of a "sequence of $element_type" type is taken, 
the subscript has the $element_type type.

9.
If a slice of a "sequence of $element_type" type is taken, each 
element still retains it's $element_type.

10.
Built in functions, where possible (append, prepend, etc), will return 
the same type as was passed to it.

11.
???Any more suggestions???

12. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by Derek Parnell <ddparnell at bigpond.com> Sep 24, 2004
• 453 views

Pete Lomax wrote:
> 
> On Thu, 23 Sep 2004 18:16:29 -0700, Derek Parnell
> <guest at RapidEuphoria.com> wrote:
> 
> >However you still have to cater for things like ...
> >
> > object Temp
> > Temp = CurrentCust
> > Temp.ZIPCode = 1234
> 
> But you cannot.
> 
> struct supplier
> 	sequence Name
> end struct
> "Name"=1 in a supplier context
> 
> <Oh dear, I think I know what you are going to say, but I'll carry on>
> 
> struct customer
> 	integer account_no
> 	sequence Name
> end struct
> "Name"=2 in a customer context
> 
> object.Name	1 or 2?
> 
> I claim that is not legal, not sensible to resolve dynamically.
> <you were, and possibly still are, thinking you could, I suspect>
> Named subscripts can only be applied, in the code, to variables
> declared of the appropriate type, I claim. I could be wrong.

Well that's one interpretation. I was thinking more along the lines that
an 'object' variable can contain any other datatype. In effect, when
you assign someting to an object, the object 'becomes' the datatype of
the assignment. So if you assign a supplier to Temp then Temp 'becomes'
a supplier struct until you assign something else to Temp. If you assign
a customer to Temp it 'becomes' in effect a customer struct.

This is consistent with the current behaviour of object variables.

-- 
Derek Parnell
Melbourne, Australia

14. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Sep 24, 2004
• 457 views

On Thu, 23 Sep 2004 19:02:53 -0700, Derek Parnell
<guest at RapidEuphoria.com> wrote:

>Well that's one interpretation. I was thinking more along the lines that
>an 'object' variable can contain any other datatype. In effect, when
>you assign someting to an object, the object 'becomes' the datatype of
>the assignment. So if you assign a supplier to Temp then Temp 'becomes'
>a supplier struct until you assign something else to Temp. If you assign
>a customer to Temp it 'becomes' in effect a customer struct.
>
I see, yes, that approach would seriously impact performance.

However I also believe that if you store a customer into an object,
you must be allowed to do rather rude things to it to turn it into a
supplier, presumably before storing it back in a supplier variable.

<aside, skip this if you like>
Just to (needlessly) pick on this particular statement:
>This is consistent with the current behaviour of object variables.

That is true for the three core datatypes of integer, atom, and
sequence. But if you have eg:

type hour(integer h)
	return h>=0 and h<=24
end type
hour h
	h=12
integer i
	i=12
object o
	o=h

then o holds 12, and, if you code it, hour(o) will return true, just
as hour(i) or hour(12) would. But o holds no information whatsoever
that the data it contains was ever an hour type, as things stand.

Philosophically, I view every variable in Euphoria as an object, with
the compiler enforcing type checks on assignment (and no doubt some
crafty performance optimisations based on the declared type).
</aside>

Regards,
Pete

16. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by Derek Parnell <ddparnell at bigpond.com> Sep 24, 2004
• 486 views

Patrick Barnes wrote:
> 
> > > Y'know, it's wonderful that a sequence can hold anything... it's much
> > > better than C-style arrays.
> > > However, can *anyone* show me a program where they've used a sequence
> > > variable that was:
> > > 1. Large.
> > > 2. Completely non-homogenous. That is, there was no underlying
> > > structure to the sequence *at all*...
> > >
> > 
> > Win32lib has the potential to do that. It uses a type of associative array
> > for some things.
> 
> Really? So there's no pattern whatsoever to the array? Can you expand
> that description?

Sure. The library supports User-Defined-Properties for each control. This
is implemented as a pair of sequences for each control. One sequence
contains text names for each property that the user defines, and the
other contains the value of each defined property. As we can't predict
the order that properties are defined in, or the datatypes that they
might have, we can end up with a sequence in which each element
has no correlation to any other element in the same sequence.

The library also supports Trackable Objects. These can be anything that
the user likes. Win32lib supplies some management functions for them but
it has no control over their contents.

> I have used N-node trees for quite a few little experiments, and they
> are a type of data that does not simply fit into a sequence...
> It ended up becoming a sequence of "nodes", where an element in the
> node contained the index of the node's parent, and an element
> contained the indexes of all the node's children.
> Homogenous. Every top-level element had the same structure.
> 
> 
> (Maybe homogenous is not the correct word.. I dunno... )

Well 'homogenous' works for me, 'hetrogenous' is its opposite. 

-- 
Derek Parnell
Melbourne, Australia

18. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by "Kat" <gertie at visionsix.com> Sep 24, 2004
• 494 views

On 24 Sep 2004, at 13:28, Patrick Barnes wrote:

>=20
>=20
> > > Y'know, it's wonderful that a sequence can hold anything... it's much=

> > > better than C-style arrays.
> > > However, can *anyone* show me a program where they've used a sequence=

> > > variable that was:
> > > 1. Large.
> > > 2. Completely non-homogenous. That is, there was no underlying
> > > structure to the sequence *at all*...
> > >
> >=20
> > Win32lib has the potential to do that. It uses a type of associative ar=
ray for
> > some things.
>=20
> Really? So there's no pattern whatsoever to the array? Can you expand
> that description?

I used getxml() for years to extract freeform unstructured data from
sequences, like this:

<h1>Cat Stevens </h1> <fld01>Cat Stevens</fld01> <br>
<fld29> </fld29> <fld18> </fld18> <br>
1. <defblk> <Syntax>propnoun,sing</Syntax>=20
<Semantic>per+male</Semantic> <def>a singer and songwriter in the USA;
wrote "Baby It's A Wild World" and "Lady D'Arbanville" for the actor and=
=20
model Patti D'Arbanville.</def> </defblk> <br>

or this:

<h1>cat </h1> <fld01>cat</fld01> <br>
<fld18>catty,cattier,cattiest,cattily,cattiness,cattish</fld18> <br>
<fld29>cats,catting,catted</fld29> <br>
<snip>
2. <defblk> <fld20>03</fld20> <Syntax>noun,sing</Syntax>
<Semantic>real+animal</Semantic> <def>a small, lithe, soft-furred animal=
=20
(<altname>Felis cattus </altname>) of this family, domesticated since
ancient times and often kept as a pet or for killing mice</def> </defblk> <=
br>


Kat=0F

20. Re: Re[2]: (Another) (small) Eu 2.5 feature request.

• Posted by "Kat" <gertie at visionsix.com> Sep 24, 2004
• 462 views

On 24 Sep 2004, at 16:53, Patrick Barnes wrote:

> 
> 
> > > Really? So there's no pattern whatsoever to the array? Can you expand
> > > that description?
> > 
> > I used getxml() for years to extract freeform unstructured data from
> > sequences, like this:
> > 
> > <h1>Cat Stevens </h1> <fld01>Cat Stevens</fld01> <br>
> > <fld29> </fld29> <fld18> </fld18> <br>
> > 1. <defblk> <Syntax>propnoun,sing</Syntax>=20
> > <Semantic>per+male</Semantic> <def>a singer and songwriter in the USA;
> > wrote "Baby It's A Wild World" and "Lady D'Arbanville" for the actor and= 
> > model Patti D'Arbanville.</def> </defblk> <br>
> > 
> > or this:
> > 
> > <h1>cat </h1> <fld01>cat</fld01> <br>
> > <fld18>catty,cattier,cattiest,cattily,cattiness,cattish</fld18> <br>
> > <fld29>cats,catting,catted</fld29> <br>
> > <snip>
> > 2. <defblk> <fld20>03</fld20> <Syntax>noun,sing</Syntax>
> > <Semantic>real+animal</Semantic> <def>a small, lithe, soft-furred animal= 
> > (<altname>Felis cattus </altname>) of this family, domesticated since
> > ancient times and often kept as a pet or for killing mice</def> </defblk> <=
> > br>
> > 
> > 
> > Kat=0F
> 
> Interesting... (sorry, can't quite read it properly, all these damned
> =20's...)
> 
> My point is, despite the fact that Euphoria *can* hold this
> unstructured data very easily...
> 
> As I have found many times, most of my programming errors are caused
> by unexpected non-homegenity (I've made a mistake in subscripting, or
> data operations).
> 
> Most programming tasks and most programmers need to use data that is
> largely homogenous... something that an improved typing mechanism
> would greatly help, especially for diagnosing errors.

Ok, associated lists, and type check it all you want before the write to the 
data sequence is done. Furthermore, you could save the data to non-
sequence memory using any of the "raw memory" manager libs (you'd likely 
need length checking at least for the raw memory stuff). then you could do 
the column addressing, know what's been stored, etc.

I don't know where the =20 came from.

Kat