OpenEuphoria

Re: Homogeneous sequence

• Posted by Juergen Luethje <j.lue at g?x.d?> Aug 14, 2007
• 660 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