Re: request for change of boolean
Kat wrote:
>
> CChris wrote:
> >
> > Kat wrote:
> > >
> > >
> > > Is it possible to change how boolean expressions are evaluated such that
> > > only
> > > values greater than 0 pass this test? :
> > >
> > > }}}
<eucode>
> > > readfile = open(flagfilename,"r")
> > > if readfile then
> > > -- it's there, process it
> > > end if
> > > </eucode>
{{{
> > >
> > > Currently, if readfile = -1 , it evaluates to TRUE, when in fact the
> > > readfile
> > > was not opened.
>
> <interesting stuff snipped>
>
> > Again, while the above two scenarios would make coding safer and clearer,
> > they
> > just don't fit in what Eu is. If I ever can get a corret type system to work
> > in Æ
>
> What is "Æ" ?
>
Æ is an acronym for Advanced Euphoria (might change without notice), which is an
unreleased attempt to add useful things to the language which can't get agreed
upon on this forum - I have no idea on how to reach the user community at large,
and the Eu community may not be the larger source of users. Currently, it's 100%
compatible with Eu, but this may dwindle to around 95% in the future. As
compatibility decreases, the likelihood of a name change will increase. I have
plans, but not much time, specially these days.
Given the time and energy Rob has poured into Eu and how he has succeeded, and
given what I can realistically marshall, it is not very likely that Æ will be
ever released. At least I can make .exe with it without some of the headaches of
Eu programming. The modified interpreter Orac uses is an early stage of Æ.
> > - not for the near future -, then the nil solution will be used.
>
>
> I liked the way bool and bytebool worked and evaluated in Pascal. Rather like
> common sense, or a checkbook. If the value was positive, any value, then it
> was there, money was in the checkbook, it was TRUE. If it was negative or
> zero,
> it was not there, there was no money, and it evaluated to FALSE.
In the strict framework of Eu, "x>0" looks to me as a good enough check.
Code clarity would certainly benefit from a strict (2 or 3 state) boolean type
being standard. And perhaps from a bytebool type as well - I'm less sure, but not
against.
> Somehow, it
> makes sense to me that Eu would have extended that to sequences (so
> {0,0,0,-300}
> = false, while {0,0,5000,0} is true).
Definitely. A sequence is true iff all its elements pass the test. I like the
way Eiffel allows to write things like:
if my_array.forall(agent some_predicate) then ...
which is exactly the same idea, just made more explicit. ("agent" is a rough
equivalent for a routine_id, but it is a full fledged object whose properties
include the arg type list, return type and stuff).
> In reality, it seems to be not only flamebait
> on my butt, but a great example of why it's a good idea to NOT provide
> specific
> code to illustrate a point.
>
> Kat
This is a double edged sword. If you don't provide code, some people won't try
to understand your point. If you do, other people will nitpick at it and forget
about the broader picture the snippet illustrates. I still think not including
example code is even worse than providing it, but that's about as good as it can
get.
CChris
|
Not Categorized, Please Help
|
|
