OpenEuphoria

Re: Source changes

• Posted by Derek Parnell <ddparnell at bigp?nd.com> Jul 03, 2007
• 637 views

Pete Lomax wrote:
> 
> Derek Parnell wrote:
> > 
> > Comments please...
> >
> >a new library called "convtext.e" will be added to Euphoria include folder.
> Good. A new include file means less impact on legacy code.

That's what I was thinking too.

> The idea of a user-definable callback, like walk_dir()/default_dir() in
> file.e,
> still appeals to me as you can make it dead easy for newbies but still have
> fine control for advanced coders.
> 
> Did you have any comments on my proposed changes to get.e?
> <a target=_top
> href="http://palacebuilders.pwp.blueyonder.co.uk/pc.htm">http://palacebuilders.pwp.blueyonder.co.uk/pc.htm</a>
> I accept the above is not going to be used, and that instead of passing a
> routine_id
> on every call, an optional set() at the start would be better.

I'm not sure what this idea gains us. What sort of things would the callback
routine do? The normal reason for callbacks is to implement an iterator, which is
called for each selected element of some set, or to modify/approve of some
activity done by the calling routine. Your code in get2.e doesn't allow for stuff
done by the callback to be passed back to the calling program so I'm not sure
what you see such callbacks doing.
 
> > 
> > -- Proposed Routines --
> > This set will attempt to convert the text to the requested format, but if
> > they are unable to they do not fail, instead they return zero.
> > 
> >  toInteger(sequence TextIn)  -- converts the text to an integer.
> >  toNumber(sequence TextIn)  -- converts the text to an integer or atom as 
> >                             -- appropriate.
> >  toDigits(sequence TextIn)  -- converts the text to an integer or atom as 
> >                             -- appropriate, but disregards all non-digits
> >                             -- except the first decimal-separator.
> >  toBase(sequence TextIn, integer Base)  -- converts the text to an
> >                                         -- integer or atom as appropriate,
> >                                         -- but disregards all non-digits as
> >                                         -- defined by the 'number-base'
> >                                         -- supplied.
> Just as an idea, I wonder:
>    text_to_data(INTEGER,xxx)
>    text_to_data(ATOM,xxx)
>    text_to_data(DIGITS,xxx)
>    text_to_data({BASE,12},xxx)
> Extendable with strings and sequences and dates and times and wotnot that way.


Hmmm... worth considering ... there might be some performance issues but I'll
give it serious thinking time.
 
> This is also very value()-sided, no equivalent get() routines.

Yeah, that's deliberate. This proposed library is not an I/O library but a text
conversion library. If you want the equivalent 'gets', then you will need to code
the shim.

  line = gets(filehandle)
  result = to_number(line)

or whatever ...


> 
> > Those routines will allow for decimal-separators, number-grouping, 
> I got lost here. I could't work out if you meant all the routines mentioned
> in the post, the ones just above, or the ones after that point. 

Ok, my bad message writing skills are evident here. <G> 

I meant all routines that parse text to find numbers will use algorithms that
take into consideration such things as decimal-separators, ... etc ...

> Actually, I
> think I'd like to see RDS-style docs for these new routines up front.

Absolutely! I'm writing those docs/specs now and will publish them for comment
before submitting library code.
 
> >  StringInt( integer Data )
     result = sprintf("%d", Data)
vs
     result = StringInt(Data)

> >  StringNumber( atom Data )

     if integer(Data) then
        result = sprintf("%d", Data)
     else
        result = trim(sprintf("%15.15f", Data))
     end if
vs
     result = StringNumber(Data)

> >  StringFormat( atom Data, sequence Format)

     result = StringFormat(Data, {"$##,###,##9.99", "$##,###,##9.99CR", "#"})
     -- This allows a different pattern for +ve, -ve and zero values.
     -- The actual currency, grouping, decimal, and credit symbols
     --   will be based on the locale data supplied. 
     -- For more examples, look at the formatting available in MS-Excel.

Also things like user-named formatting strings will be available ...

     define_formatter("StdCurrency", {"$##,###,##9.99",    -- +ve
                                      "$##,###,##9.99CR",  -- -ve
                                      "#"                  -- zero
                                     })
     result1 = StringFormat(Data1, {"&StdCurrency"})
     result2 = StringFormat(Data2, {"&StdCurrency"})
     result3 = StringFormat(Data3, {"&StdCurrency"})
     result4 = StringFormat(Data4, {"&StdCurrency"})

also this can be done as 

     result = StringFormat({Data1, Data2, Data3, Data4}, 
                           {"&StdCurrency"})
     -- giving a 4-element sequence of formatted numbers.
     
> Without examples I see no gain over sprint(f).

That enough for now?

 
> >  DateFormat ( sequence Data, sequence Format)
> >  TimeFormat ( atom Data, sequence Format)
> >  CurrencyFormat (atom Data)
> 
> I would, for example, hope to see in RDS-style docs that DateFormat etc should
> only be used for display and reporting purposes; saving data to file should
> use the rawest possible format, eg {2007,7,2} not "2nd July 2007", otherwise
> a user in a different locale may not be able to read the data.

Yes, but that is not a fault of a library. <G>

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