OpenEuphoria

1. Discussion concerning [POLL] Sequences of types

• Posted by Juergen Luethje <j.lue at ?m?.de> Aug 24, 2007
• 733 views

To all people who voted 3. UNRESTRICTED:

Are you aware that this is a good source for causing nightmares
(as has been discussed previously)?

Regards,
   Juergen

3. Re: Discussion concerning [POLL] Sequences of types

• Posted by Juergen Luethje <j.lue at ?mx.?e> Aug 24, 2007
• 661 views

Derek Parnell wrote:

> Juergen Luethje wrote:
> > 
> > To all people who voted 3. UNRESTRICTED:
> > 
> > Are you aware that this is a good source for causing nightmares
> > (as has been discussed previously)?
> 
> I've been busy so I might have missed that discussion.

I see now that this is actually a big problem.
So I strongly suggest that everyone who makes a poll, not only asks
"Would you prefer A or B?", but also SUMMARIZES THE PROS AND CONS OF THE
OPTIONS, according to the previous discussion.

> I can't see why it would be any more a problem being unrestricted than being
> restricted to user-defined-types.
> 
>   integer list X  -- only integers can be placed in this.
> 
> where is the problem?
> 
>   type mt (integer list A)
>      return 1
>   end type
>   mt X -- only integers can be placed in this.
> 
> Why is there a difference?

Say we have something like
   names = {"Tom", "Mary", "Bob"}

If the new syntax is not restricted, then at least each of the following
would be syntactically correct:
   object names
   sequence names
   sequence of sequence names
   sequence of sequence of object names
   sequence of sequence of atom names
   sequence of sequence of integer names

and maybe even
   object of sequence names
   object of sequence of object names
   object of sequence of atom names
   object of sequence of integer names

or
   sequence of object names
   sequence of object of object names
   sequence of object of atom names
   sequence of object of integer names

or
   object of object names
   object of object of object names
   object of object of atom names
   object of object of integer names

( Maybe I forgot a possibility. )

This is very confusing, especially for beginners, and has IMHO nothing
got to do with the spirit of Euphoria.

That's why Pete Lomax suggested to restrict the new syntax to the
definition of types. Then w'd have to create a user-defined type say
"word_list", and in our programs we just say:
   word_list names

I'm strongly against the introduction of the new type syntax without
this restriction.

Regards,
   Juergen

5. Re: Discussion concerning [POLL] Sequences of types

• Posted by c.k.lester <euphoric at c?le?ter.com> Aug 24, 2007
• 664 views

Juergen Luethje wrote:
> 
> Say we have something like
>    names = {"Tom", "Mary", "Bob"}
> 
> If the new syntax is not restricted, then at least each of the following
> would be syntactically correct:
>    object names
>    sequence names
>    sequence of sequence names
>    sequence of sequence of object names
>    sequence of sequence of atom names
>    sequence of sequence of integer names
> 
> and maybe even
>    object of sequence names
>    object of sequence of object names
>    object of sequence of atom names
>    object of sequence of integer names
> 
> or
>    sequence of object names
>    sequence of object of object names
>    sequence of object of atom names
>    sequence of object of integer names
> 
> or
>    object of object names
>    object of object of object names
>    object of object of atom names
>    object of object of integer names

That's really horrendous. LOL! :D

> I'm strongly against the introduction of the new type syntax without
> this restriction.

I strongly agree with you.

7. Re: Discussion concerning [POLL] Sequences of types

• Posted by Matt Lewis <matthewwalkerlewis at gm?il.?om> Aug 24, 2007
• 685 views

Juergen Luethje wrote:
> 
> To all people who voted 3. UNRESTRICTED:
> 
> Are you aware that this is a good source for causing nightmares
> (as has been discussed previously)?
> 
That's OK.  I predict that this proposal passes overwhelmingly, but never
gets implemented.  Rob has discussed this several times, but I doubt many
people realize (because they've never really worked with the source code)
how large a change it is to add some new data type.

I could be wrong, of course.  But really, I don't see what this proposal
really adds to the language.  The only advantage that I can see is that
some of the type checking for certain UDTs can be done by the back end.

Of course, if it gets as ingrained as checking for sequence/atom/integer,
then it's going to really slow things down, since those checks happen
regardless of whether type checking is turned on.  And that usually only
happens during debugging, not for production, so speed isn't nearly so
critical.

I think that this is really a false start at some sort of structured 
data type for euphoria, which would have benefits, because you'd have
more ability to do type checks on individual pieces of data and structured
access to data members that wouldn't pollute the namespace.  That's 
the sort of thing that would be really useful.

Matt

9. Re: Discussion concerning [POLL] Sequences of types

• Posted by Pete Lomax <petelomax at blu?yonder?co.uk> Aug 24, 2007
• 668 views

Matt Lewis wrote:
> 
> I don't see what this proposal
> really adds to the language.  The only advantage that I can see is that
> some of the type checking for certain UDTs can be done by the back end.
Yup. For detailed type checking that is currently completely impractical,
however, that is no small thing.

> I think that this is really a false start at some sort of structured 
> data type for euphoria
I daresay I agree with you.

The current vote is a subset of what has recently been discussed, and hopefully
there is more to come. But a start is a start.

Regards,
Pete

11. Re: Discussion concerning [POLL] Sequences of types

• Posted by Matt Lewis <matthewwalkerlewis at g?ail.co?> Aug 24, 2007
• 668 views

Pete Lomax wrote:
> 
> Pete Lomax wrote:
> > 
> > Matt Lewis wrote:
> > > 
> > > I don't see what this proposal
> > > really adds to the language.  The only advantage that I can see is that
> > > some of the type checking for certain UDTs can be done by the back end.
> >
> > Yup. For detailed type checking that is currently completely impractical,
> > however,
> > that is no small thing.
> > 
> Actually I do wonder how many people think this is adding something new and
> powerful
> and exciting to the language? All this stuff will ever do is allow you to make
> your program crash earlier&faster when there is a bug in it.

Yes, exactly!  I can't get my head around the usefulness of this.  As I see 
it, there are two basic reasons to use the euphoria type checking capabilities.

One is for debugging, to ensure that data is correct.  I don't really see 
this as hugely benefiting from the speed up, and I also believe that the 
massive changes required to the interpreter are not worth the minimal benefit.

The second is to discriminate between different kinds of data (like your
chess boards, board, row example).  For deeply nested data that requires
a lot of checking, this is probably a poor method.  Better would be 
to tag the data with some kind of metadata to identify what it is (you 
could still use type checking while debugging).

Which explains my 'No' vote.

Matt

13. Re: Discussion concerning [POLL] Sequences of types

• Posted by Matt Lewis <matthewwalkerlewis at gmai?.co?> Aug 24, 2007
• 646 views

Pete Lomax wrote:
> 
> > I think that this is really a false start at some sort of structured 
> > data type for euphoria
>
> I daresay I agree with you.
> 
> The current vote is a subset of what has recently been discussed, and
> hopefully
> there is more to come. But a start is a start.

I just think it's a blind alley.  I think that what people really want
(even if they don't know it yet :P ) is the native ability to have some kind 
of structured data, but the reason for this is not to enforce types (which
can already be done) but to simplify the use of the data.

I still believe that the 'euclass' facilities of ooeu are a step in the 
right direction.  One advantage of it is that the changes are all 
in the front end.  Pure vanilla Euphoria IL is emitted (though I think that
ultimately there are some things that will require some backend work).

It occurred to me today that there's an 'easy' way to
store metadata to allow some powerful extensions of this concept without 
having to change lots of stuff.  Currently, the 0th element 
(seq_ptr->base[0]) of a sequence sits emtpy, but we could put
a pointer to a struct of metadata that could hold information to allow
better type checking, virtual functions, inheritance, etc.

In any case, there's a lot to figure out, but it's at least useful, and,
IMHO very worthy of consideration.

Matt

15. Re: Discussion concerning [POLL] Sequences of types

• Posted by Matt Lewis <matthewwalkerlewis at ?m?il.com> Aug 24, 2007
• 684 views

Juergen Luethje wrote:
> 
> Well, actually it will also allow programs to run faster when type-
> checking is switched on and there is no crash. In those cases, debugging
> would be considerably faster for certain programs. This makes it more
> convenient for programmers to switch type-checking on for debugging, and
> so will encourage them to actually do so. This can help to find bugs and
> so make their programs safer.
> I think a good overview about the pros and cons is in Robs first post in
> the current discussion about UDTs:
>
> http://www.openeuphoria.org/cgi-bin/esearch.exu?fromMonth=6&fromYear=C&toMonth=8&toYear=C&postedBy=Robert+Craig&keywords=22%3A26+type

Yes, I agree with that, however, my personal assessment (as someone who has
extended/maintained the interpreter) is that the following statement of 
Rob's dominates the equation:

  * 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'm happy to be proved wrong, however.  I suppose one nice benefit is that
you could do a lot more (in an easier fashion ) at compile time, even in
the interpreter, to catch bugs much sooner.

Matt

17. Re: Discussion concerning [POLL] Sequences of types

• Posted by Matt Lewis <matthewwalkerlewis at ??ail.com> Aug 24, 2007
• 662 views

Juergen Luethje wrote:
> 
> From several discussions in the past, I think many people (including me)
> would greatly appreciate to have some sort of structured data type in
> euphoria. Do you think it's possible to get that without too much effort
> and trouble?
> 
Yes.  I see this as probably the most significant enhancement to the language
that's been proposed so far, although I think the 'structured sequence'
feature request on sourceforge isn't complete.

I think that ooeu made a good start at structured data.  Here are a some
links to the docs:

http://ooeu.sourceforge.net/docs/CLASS_SPECIFICATION.htm
http://ooeu.sourceforge.net/docs/DOT_NOTATION.htm

Disregard the OOPishness if you like, and omit the routines, at least for
now.  This could also further the goal of encapsulation (to a point, at 
least) by limiting the visibility of members/routines of a structure 
(ooeu doesn't do this).

Since the front end would know about the data when it's assigned, we could
emit a type check instruction (assuming it's not verifiable at compile time)
for the appropriate data type (thus getting the cheaper type checking that 
the "Sequences of types" proposal seems to give).

We also get all the goodness of not having to declare lots of constants
for accessing the data.  Not to mention that if we had this sort of thing,
we could build IDEs with code completion--anyone who's used Visual Studio,
Eclipse or some similarly powerful IDE can attest that this is a big
helper:  reduce typing, errors, coding time.

Matt

19. Re: Discussion concerning [POLL] Sequences of types

• Posted by Matt Lewis <matthewwalkerlewis at ?mai?.com> Aug 24, 2007
• 657 views

CChris wrote:
> 
> Pete Lomax wrote:
> > 
> > Actually I do wonder how many people think this is adding something new and
> > powerful
> > and exciting to the language? All this stuff will ever do is allow you to
> > make
> > your program crash earlier&faster when there is a bug in it.
> 
> I so dearly wish I had it available when I was debugging the new win32lib
> structure
> engine, which has structured sequences whose description is sometimes subtle.
> Iy would have cut debug time by probably one half, if not more. Counting in
> weeks.

Could you please explain more fully?  Is there a reason why you couldn't have
used the existing UDT system?

Matt

21. Re: Discussion concerning [POLL] Sequences of types

• Posted by Derek Parnell <ddparnell at ?igpond.c?m> Aug 25, 2007
• 704 views

Juergen Luethje wrote:
> 
> Derek Parnell wrote:
> 
> > Juergen Luethje wrote:
> > > Say we have something like
> > >    names = {"Tom", "Mary", "Bob"}
> > > 
> > > If the new syntax is not restricted, then at least each of the following
> > > would be syntactically correct:
> > >    object names
> > >    sequence names
> > >    sequence of sequence names
> > >    sequence of sequence of object names
> > >    sequence of sequence of atom names
> > >    sequence of sequence of integer names
> > 
> > Yes, they are all syntactically correct, but each has a different semantics.
> > 
> >   object names -- Can be assigned with anything.
> >   sequence names -- Can only be assigned with a sequence.
> >   sequence of sequence names -- Can only contain sequences.
> >   sequence of sequence of object names -- same as above.
> >   sequence of sequence of atom names -- Can only contain sequences, which
> >                                       -- can only contain atoms
> >   sequence of sequence of integer names -- Can only contain sequences, which
> >                                       -- can only contain integers
> 
> I know that each one has a different semantics, but that's not my point.


I think that you are saying that each of these things are equivalent to each
other and thus there is multiple ways to declare the same 'type' of variable, and
this is potentally confusing.

However I am saying that these are not the same 'type' of variable. That each
one is a different type. As different as one can find in C, for example ...

  int names;
  long names;
  char* names;
  char[45] names;
  float names;


Semantics is what makes them different.

To further emphasize my point, if one were to imlement the same functionality in
current Euphoria, one would use UDT, thus demonstrating that they are actually
different types.

type SoS(object x) -- Can only contain sequences.
   if not sequence(x) return 0 end if
   for i = 1 to length(x) do
       if not sequence(x[i]) return 0 end if
   end for
   return 1
end type

type SoSoO(object x) -- Can only contain sequences, which
                     -- can only contain objects
   if not sequence(x) return 0 end if
   for i = 1 to length(x) do
       if not sequence(x[i]) return 0 end if
       for j = 1 to length(x[i]) do
           if not object(x[i][j]) then return 0 end if
       end for
   end for
   return 1
end type

type SoSoA(object x) -- Can only contain sequences, which
                     -- can only contain atoms
   if not sequence(x) return 0 end if
   for i = 1 to length(x) do
       if not sequence(x[i]) return 0 end if
       for j = 1 to length(x[i]) do
           if not atom(x[i][j]) then return 0 end if
       end for
   end for
   return 1
end type

type SoSoI(object x) -- Can only contain sequences, which
                     -- can only contain integers
   if not sequence(x) return 0 end if
   for i = 1 to length(x) do
       if not sequence(x[i]) return 0 end if
       for j = 1 to length(x[i]) do
           if not integer(x[i][j]) then return 0 end if
       end for
   end for
   return 1
end type

object names -- Can be assigned with anything.
sequence names -- Can only be assigned with a sequence.
SoS names -- Can only contain sequences.
SoSoO names -- Can only contain sequences that only contain objects
SoSoA names -- Can only contain sequences that only contain atoms
SoSoI names -- Can only contain sequences that only contain integers

So you see if the proposal is confusing then Euphoria is already just as
confusing.

> > If this is too much for some people to grok then maybe a simplified 'type'
> > alias
> > might be useful.
> > 
> >    type word_list (sequence of sequence of integer)
> >    end type
> 
> We do not need an alias mechanism if we do things properly in the first
> place. Only allowing the new syntax in type definitions like this was
> the core of Pete's proposal.

But WHY? It takes more typing, more reading and achieves nothing extra.

> > > and maybe even
> > >    object of sequence names
> > >    object of sequence of object names
> > >    object of sequence of atom names
> > >    object of sequence of integer names
> > 
> > Well, the above would not be valid
> 
> Maybe, maybe not. We can't know that for sure until it would be
> implemented.

Hmmm... think about it a bit more. An "object of sequence" is an object that
must only be assigned with a sequence as the left hand side expression. Thus it
is identical to what we now call a "sequence". Thus "object of sequence" is
longhand for "sequence".
 
> > as they don't start with "sequence".
> > 
> >  
> > > or
> > >    sequence of object names
> > >    sequence of object of object names
> > >    sequence of object of atom names
> > >    sequence of object of integer names
> > 
> > However, 'sequence' by itself is already an abbreviation for 'sequence of
> > objects'.
> > 
> > > This is very confusing, especially for beginners, and has IMHO nothing
> > > got to do with the spirit of Euphoria.
> > 
> > If its the wordiness that worries you then we can solve that with an alias
> > mechanism.
> 
> One problem is that it can reduce redability. Things like
>   object foo
>   sequence bar
> etc. can be read quickly and reliably at one glance. This is not the
> case for variable declarations like above,

Oh I agree that it would be poor coding practice for people to do any more than
one level of 'X of Y' just on legibilty grounds. However, conceptually there is
nothing wrong with the idea so therefore a shorthand 'alias' would enable both
the concept and the practically of coding it to co-exist.

>  especially since there are
> _many_ different possibilities to declare the same variable.

See above. They are not the 'type' so they are not declaring the same (way to
use the) variable.

Literally "different possibilities to declare the same variable" is already
present in the language. eg.

object names
sequence names
integer names
atom names
myUTD names

These above all declare the same variable (name) but with different semantics.

> Another problem is that it has a good potential to cause confusion.
> Imagine a newbie who wants to declare 'names'. Which of the available
> 14 (or 18, that doesn't matter) options should s/he use?

The one that implements the semantics that they desire for their application.
That was an easy one.

> > And exactly what is "the spirit of Euphoria"?
> 
> You know very well that it's not possible to give an exact definition of
> it.

That was exactly my point. It isn't possible because when we get to the detail
level everyone has a different opinion.

> However, there is something like that. You can call it the "core
> principles of Euphoria" or something similar, if you prefer.
> 
> Certainly _not_ among the core principles of Euphoria is 
...
> making things unnecessarily complicated, 

  if compare(Seq1, Seq2) < 0 then ... 

(Yeah, that is much more simplier than "if Seq1 < Seq2 then ... ")

> confusing newbies, 

See above...

> and providing lots of
> different options for the same thing.

 if equal(A,B) then ...
 if compare(A,B) = 0 then ...
 if A = B then ...

> Actually one of Euphoria's principles is to reduce the number of choices
> which the programmer has to made. This is what makes the language simple,
> clean and good readable.

Does this also mean that the langauge with fewer choices is the better one? What
think ye of Forth? Or BrainFuck?

> > I don't really think that this concept, which is used in other languages, is
> > all that baffling to newbies and oldbies alike.
> 
> I don't know any other language that provides 14 or 18 different
> possibilities for declaring the same variable.

Try C/C++

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

23. Re: Discussion concerning [POLL] Sequences of types

• Posted by Juergen Luethje <j.lue at gm??de> Aug 25, 2007
• 674 views

Derek Parnell wrote:
> 
> Juergen Luethje wrote:
> > 
> > Derek Parnell wrote:
> > 
> > > Juergen Luethje wrote:
> > > > Say we have something like
> > > >    names = {"Tom", "Mary", "Bob"}
> > > > 
> > > > If the new syntax is not restricted, then at least each of the following
> > > > would be syntactically correct:
> > > >    object names
> > > >    sequence names
> > > >    sequence of sequence names
> > > >    sequence of sequence of object names
> > > >    sequence of sequence of atom names
> > > >    sequence of sequence of integer names
> > > 
> > > Yes, they are all syntactically correct, but each has a different
> > > semantics.
> > > 
> > >   object names -- Can be assigned with anything.
> > >   sequence names -- Can only be assigned with a sequence.
> > >   sequence of sequence names -- Can only contain sequences.
> > >   sequence of sequence of object names -- same as above.
> > >   sequence of sequence of atom names -- Can only contain sequences, which
> > >                                       -- can only contain atoms
> > >   sequence of sequence of integer names -- Can only contain sequences,
> > >   which
> > >                                       -- can only contain integers
> > 
> > I know that each one has a different semantics, but that's not my point.
> 
> 
> I think that you are saying that each of these things are equivalent to each
> other

No. I didn't say that. Just read my post carefully. It's understandable.
In order to understand the "whole story", it's probably necessary to watch
the video that I recommended.

Regards,
   Juergen

25. Re: Discussion concerning [POLL] Sequences of types

• Posted by Juergen Luethje <j.lue at gm?.?e> Aug 25, 2007
• 665 views

Matt Lewis wrote:

> Juergen Luethje wrote:
> > 
> > From several discussions in the past, I think many people (including me)
> > would greatly appreciate to have some sort of structured data type in
> > euphoria. Do you think it's possible to get that without too much effort
> > and trouble?
> > 
> Yes.  I see this as probably the most significant enhancement to the language
> that's been proposed so far, although I think the 'structured sequence'
> feature request on sourceforge isn't complete.
> 
> I think that ooeu made a good start at structured data.  Here are a some
> links to the docs:
> 
> <a
> href="http://ooeu.sourceforge.net/docs/CLASS_SPECIFICATION.htm">http://ooeu.sourceforge.net/docs/CLASS_SPECIFICATION.htm</a>
> <a
> href="http://ooeu.sourceforge.net/docs/DOT_NOTATION.htm">http://ooeu.sourceforge.net/docs/DOT_NOTATION.htm</a>
> 
> Disregard the OOPishness if you like, and omit the routines, at least for
> now.  This could also further the goal of encapsulation (to a point, at 
> least) by limiting the visibility of members/routines of a structure 
> (ooeu doesn't do this).
> 
> Since the front end would know about the data when it's assigned, we could
> emit a type check instruction (assuming it's not verifiable at compile time)
> for the appropriate data type (thus getting the cheaper type checking that 
> the "Sequences of types" proposal seems to give).
> 
> We also get all the goodness of not having to declare lots of constants
> for accessing the data.  Not to mention that if we had this sort of thing,
> we could build IDEs with code completion--anyone who's used Visual Studio,
> Eclipse or some similarly powerful IDE can attest that this is a big
> helper:  reduce typing, errors, coding time.
> 
> Matt

Cool! That sounds exciting.

Regards,
   Juergen

27. Re: Discussion concerning [POLL] Sequences of types

• Posted by DB James <larches at comcast.n?t> Aug 27, 2007
• 666 views

Have been distracted, computer died, resurrection fraught, voting:

YES

A

UNRESTRICTED

UNRESTRICTED

UNRESTRICTED

--Quark