1. Some changes I'd like to see
Here are some thoughts on changes I would make if I were designing
a new version of Euphoria. It would appear that none of these are
impossible,
since similar things can be found in some Euphoria functions already.
CONSTANTS:
Constants should be extended to include a range, i.e.
constant summer_months = 7..9
VARIABLE TYPES:
sequence -- extended to hold typed variables when used as an array. See
ARRAY:
new string type -- see STRINGS
user-defined types extended -- see UDTs
ARRAY: (typed sequences)
string season -- declare an instance of type string
sequence seasons = repeat(season,4) -- initialize the array to be of type
string
seasons = {"Winter","Spring","Summer","Fall"}
seasons[3] = 45 -- error
Existing untyped sequences remain as they are now (containers of objects)
STRINGS:
Implementing a string type will allow Euphoria to store "Hello World" as
"Hello World" (13 bytes)
instead of {72,101,108,108,111,32,87,111,114,108,100} (42 bytes)
thus preventing menory and disk from getting that uncomfortable bloated
feeling.
UDTs:
Type () should be extended. Currently the user-defined type() functions can
only
do one of two things: In case 1, the assignment takes place as normal, and
in case 2, the program aborts with an error. There are no other options.
Better would be to allow the type() function to pass a new value back to be
used in the assignment. Thus it would be possible to FIX the problem, either
by substituting a valid default value, calling functions to ask the user to
try again, or by other means. When fixing is impossible, the programmer can
always call abort() from within the type() routine.This could save hundreds
of lines of input checking code in a long,
interactive program, but its utility hinges on Rob being able to speed up
user-defined type checking.
MULTIPLE REFERENCES:
-- By using the comma and range (..) operators, sequences and objects
-- could be addressed in a more natural way. See examples below.
-- puts() should able to iterate thru a {list} of variables, as does
-- printf(), except that since puts() doesn't require a series of format
strings,
-- it would be irrelevant how many items were passed in the list.
-- Declare and initialize some individual (unstructured) variables
string name = "Bubba",
addr = "1234 Fifth St.",
city = "New Jerk City",
state = "NJ",
zip = "12345",
phone = "555-1234"
integer hours = 40
atom rate = 12.50
atom net = 0
sequence payrecord = repeat(net,52) -- typed array, one for each week of the
year
sequence notes = {} -- untyped variable, empty
puts(1,name) -- prints Bubba to the screen
puts(fn,name) -- prints "Bubba" to the disk
net = rate * hours -- figure and store
payrecord[4] = net
puts(1,{name, phone, net}) -- prints Bubba 555-1234 500 to screen
puts(fn,{name, phone, net}) -- prints "Bubba","555-1234",500 to disk
printf(1,"Paid %s $%8.2f",{name,payrecord[4]}) -- prints Paid Bubba $500.00
puts(1 "Bubba's first four paychecks:\n ") -- Bubba's first four paychecks:
puts(1, payrecord[1..4]) -- 0 0 0 500
STRUCTURES:
object employee = {name,addr,city,state,zip,hours,rate, payrecord, notes}
--Tthis means: inside the object "employee" there are instances of the
following
-- already-declared typed variables: name, addr, city......payrecord
-- and the untyped sequence notes. They are stored and enumerated in that
order, and
-- can be addressed as employee[1], employee[2]...employee[8][2]
-- OR by the name given to them in this declaration.
-- Inside the square brackets, "name" is the equivalent of 1, "addr" is 2,
--"payrecord" is the same as 8....
-- Outside the brackets, payrecord is an array of 52 atoms, and hours is an
integer
--variable, distinct and separate from employee[payrecord] or
employee[hours],
-- Untyped, empty object can still be declared in the normal way.
constant home_address = 1..3 -- range constant
name = "George"
put(1,name) -- prints George on the screen
put(1,employee[name]) -- prints Bubba on the screen
put(1,employee[name,rate]) -- prints Bubba 12.50
put(1,employee[name..city, rate]) -- prints Bubba 1234 Fifth St New Jerk
City 12.50
put(1,employee[home_address, rate]) -- same as above
A list of employees would be declared as a typed sequence:
sequence employee_list = repeat(employee,100)
which could be appended, referenced, saved to disk, etc. in the usual way.
All that should generate some conversation.
Irv
2. Re: Some changes I'd like to see
<Snip...>
> STRINGS:
> Implementing a string type will allow Euphoria to store "Hello World" as
> "Hello World" (13 bytes)
> instead of {72,101,108,108,111,32,87,111,114,108,100} (42 bytes)
> thus preventing menory and disk from getting that uncomfortable bloated
> feeling.
<Snip...>
AFAIK (As Far As I Know), the string "Hello World" is stored in memory as
"Hello World", not as the euphoria sequence. This is just euphorias way of
displaying sequences in an easy to read form, and printing to disk is just
another type of displaying, as far as euphoria is concerned. Of course,
printf can be used to ovveride the default display method.
Nick
3. Re: Some changes I'd like to see
- Posted by Everett Williams <rett at GVTC.COM>
Feb 01, 2000
-
Last edited Feb 02, 2000
On Wed, 2 Feb 2000 12:39:15 +1300, The Johnson Family <thedjs at INAME.COM>
wrote:
><Snip...>
>> STRINGS:
>> Implementing a string type will allow Euphoria to store "Hello World" as
>> "Hello World" (13 bytes)
>> instead of {72,101,108,108,111,32,87,111,114,108,100} (42 bytes)
>> thus preventing menory and disk from getting that uncomfortable bloated
>> feeling.
><Snip...>
>AFAIK (As Far As I Know), the string "Hello World" is stored in memory as
>"Hello World", not as the euphoria sequence. This is just euphorias way of
>displaying sequences in an easy to read form, and printing to disk is just
>another type of displaying, as far as euphoria is concerned. Of course,
>printf can be used to ovveride the default display method.
>
>Nick
Well, we're really not supposed to know how it is stored in memory, but the
good book( the Euphoria documentation) indicates sequences and strings
are one and the same thing and there is no real distinction between the
binary numbers that represent ASCII strings and the strings themselves.
According to that logic, Irv has the right of it on this one.
Everett L.(Rett) Williams
rett at gvtc.com
4. Re: Some changes I'd like to see
> On Wed, 2 Feb 2000 12:39:15 +1300, The Johnson Family <thedjs at INAME.COM>
wrote:
>
> ><Snip...>
> >> STRINGS:
> >> Implementing a string type will allow Euphoria to store "Hello World"
as
> >> "Hello World" (13 bytes)
> >> instead of {72,101,108,108,111,32,87,111,114,108,100} (42 bytes)
> >> thus preventing menory and disk from getting that uncomfortable bloated
> >> feeling.
> ><Snip...>
> >AFAIK (As Far As I Know), the string "Hello World" is stored in memory as
> >"Hello World", not as the euphoria sequence. This is just euphorias way
of
> >displaying sequences in an easy to read form, and printing to disk is
just
> >another type of displaying, as far as euphoria is concerned. Of course,
> >printf can be used to ovveride the default display method.
> >
> >Nick
>
> Well, we're really not supposed to know how it is stored in memory, but
the
> good book( the Euphoria documentation) indicates sequences and strings
> are one and the same thing and there is no real distinction between the
> binary numbers that represent ASCII strings and the strings themselves.
> According to that logic, Irv has the right of it on this one.
>
> Everett L.(Rett) Williams
> rett at gvtc.com
>
Hold on just a mo, Irv is saying that if we 'looked' into the memory, we
would see the character codes for {72,101,108,108,111,32,87,111,114,108,100}
(42 char codes) instead of just the character codes for "Hello World". What
I gather from the manual is that yes, characters and integers are stored the
same, but they are not stored in memory as ASCII text - the number 65535
would not consist of character codes for each character (6, 5, 5, 3, and 5),
but as a 2 byte binary number. The same with character codes - they would be
stored as a 1 byte binary number for each character. Am I making sense here?
Maybe RDS can sort this out for us, because if things are stored in Mem as
Irv suggests, numbers are stored even less efficiently than strings, using 8
bits per decimal digit.
Nick
5. Re: Some changes I'd like to see
- Posted by Everett Williams <rett at GVTC.COM>
Feb 01, 2000
-
Last edited Feb 02, 2000
I think that is 4 bytes per number or per binary equivalent of ASCII character.
Everett L.(Rett) Williams
rett at gvtc.com
