OpenEuphoria

Re: ? 1={}, is there really any other interpretation?

• Posted by Pete Lomax <petelomax at bl?eyond?r.co.uk> Jul 17, 2007
• 682 views

Derek Parnell wrote:
> I have a point now, actually. To make it easier for humans to create programs
> is why we have programming languages, therefore the languages should help
> humans
> do their job. Keeping poorer aspects of a language in place needs to be
> justified,
> as does changing them. We need to examine, empirically, the true cost of
> making
> Euphoria better. 

Well said.

One thing that just struck me is that we could probably do some worthwhile
experiments in eu.ex / execute.e, eg change:

procedure opGREATER()
    a = Code[pc+1]
    b = Code[pc+2]
    target = Code[pc+3]
--  val[target] = val[a] > val[b]
    val[target] = compare(val[a],val[b]) > 0
    pc += 4
end procedure

and similar changes (this list may not be complete) for opGREATER_IFW(),
opNOTEQ_IFW(), opLESSEQ_IFW(), opGREATEREQ_IFW(), opEQUALS_IFW(), opLESS_IFW(),
opLESS(), opEQUALS(), opNOTEQ(), opLESSEQ(), opGREATEREQ().

It may also be an idea to make opOR() and opAND() invoke RTFatal() when given
sequence operands (as part of this experiment).

Obviously we know that quite a few things will break. It is reasonable to deal
with/replace upper() and lower() before commencing.
Interesting points for me would be:
  How often does a run-time (or hopefully in future compile-time) error 
  point directly at, or close enough not to matter, to the line needing 
  change?
  How long does it take to get each broken program running again?
  What merits/costs does "with old_seq_ops" have for legacy code?

Regards,
Pete
PS In case it helps, my collection of 35 sq_ wrappers can be found here:
http://palacebuilders.pwp.blueyonder.co.uk/psqop.htm