Re: Stupid Newbie-sounding question.
Patrick Barnes wrote:
>
> >From: Robert Craig <guest at RapidEuphoria.com>
> >Subject: Re: Stupid Newbie-sounding question.
> >This idea has come up before.
> >I haven't ruled it out.
> >I was quite interested in this a few years ago.
> >As I recall, the thing that made me lose some
> >interest was the fear that few people
> >would use it, and it wouldn't provide a great deal
> >of benefit to those who did use it. It would
> >also make the language more complicated,
> >not to mention verbose.
> >
> >In other languages, you need types in order to
> >define the layout of your data in memory.
> >In Euphoria, a type is just a documentation
> >and debugging aid, and few people seem to
> >bother defining them.
> >
> Um, that's like saying "I don't need to replace the broken bicycle, no one
> is using it"...
>
> The main issue with Euphoria's sequences is that they're so damn flexible
> that it can be confusing!
> Issue #1:
> function myFunc(sequence r1, sequence r2, sequence r3)
>
> Okay Rob... What sort of structure do these sequences have to have? I don't
> know! If we had the ability to use stronger typing, then function
> myFunc(text_picture r1, string r2, flag_list r3) would make a lot more
> sense. I could go and look at the type declaration, and figure out what to
> pass to the function.
> People don't use the types like this at the moment because it's so damn
> computationally expensive for sequences.
This is true. And there is the trade off - speed & flexibility against
structure and complexity. Think of it in terms of a bicycle without
training wheels and one with training wheels 
RDS has chosen speed. Meaning that the coder has more responsibility to
provide quality assurance than the translator does. Yes this does mean
more work for the coder and better discipline.
Would you prefer a slower Euphoria if it had structures, strings and
an improved type system? If so, you may have to wait until v2.5 comes out
and someone adds these to the slower version.
> Issue #2:
> Run-time slicing and sequence errors are my main cause of problems. The
> primary error I make is missing a set of braces around a concatenation
> command....
> type vector(sequence s)
> return length(s) = 2 and atom(s[1]) and atom(s[2])
> end type
> type vector_list(sequence of vector s)
> return 1
> end type
> vector_list vectors
> vectors = getVectors()
> Say I wanted to add a vector to that list (and I'm not quite paying enough
> attention)
> vectors &= NewVector(30, 20)
> Hmm... Unbeknownst to me, the last two elements of vector are now 30 and
> 20... not the last element being {30,20} like i'd hoped.
>
Learn to love the append() function.
'append' adds ONE element, the source, to a sequence. newlength = oldlength +
1.
'&' adds all the source elements to a sequence. newlength = oldlength +
sourcelength.
Another way of visualizing this is that '&' is like joining together two
sets of train carriges together. 'append' joins one new carriage and places
all the new stuff into that new carriage.
> Unfortunately, I only find out when I try to reference it, which may be a
> long way from this error. At least with differential checking, an error
> would show up at that point of error, and I can fix it quicker.
This is also an arguement for some type of 'assert' system that would help
trap errors during development and could be automatically removed for the
release version.
> While we're talking about types, it would be nice if:
> Should the checked variable be an incompatible type with the parameter, it
> will just return 0, not crash the interpreter:
> type myStruct (sequence s)
> if -------- return 1
> else return 0
> end type
>
> object x
> ...
> x = 0
> ...
> if myStruct(x) then return 1 end if
> ...
> This crashes.
>
> That would actually help "of"s case.
>
> I think that having types like this would make the language *easier* to
> understand, not more complex. Especially, it would make someone elses code
> easier to read.
Ummmm? Why not code so that it works?
type myStruct (object s)
if sequence(s) return 1
else return 0
end type
--
Derek Parnell
Melbourne, Australia
|
Not Categorized, Please Help
|
|
