Marcus / Everybody,

Hi there,

You made some very interesting & pertinent points
in your posts, here's a few quick replies &
queries.

Firstly, your datamodel ideas are of much interest
to me, just to ensure i understand your proposals
fully, could you please perhaps show me by way of
examples how you might implement a few particular
datatypes. Integer! Decimal! Block! String! etc.

About decimal!, im my earlier post you will see
that the REBOL docs do in fact say they are 64bit
double precision values.

Secondly, your comments about my new / user defined
datatype ideas.

Regards Ascii & Unicode string! types. I wanted to
try to keep the concept of string syntax very similar
to what REBOL currently has where "" & {} are pretty
much interchangeable and deeply quoted strings are
quite trivial by mixing and matching quotes "" or
braces {}.

I chose to keep ascii char! #"A" types as is, so if
we follow on from that logic then ascii string! should
also use quotes "". I chose to use #'A' form for unicode
char! as I thought SINGLE tick ' would be more easy to
remember in association with UNIcode, besides #{} is
already used for other things, in keeping with REBOL
string syntax though braces {} seemed to be the right
choice for unicode string!.

As Larry Wall of Perl would say
"Things that are different should look different"
so hence "" for ascii and {} for unicode.

I didn't want things to look too different though as
I like syntax to be unobtrusive and elegant and not
in your face butt ugly syntax like perl.

However using quotes for ascii and braces for unicode
presents us with two little problems. First one is quite
trivial in that in REBOL quotes for single line strings
and braces for multi-line strings, well at least at the
console input. That is easy solved, and strings can
remain open across multi-lines until they are terminated
by the string closing character(s). Second problem which
requires a little bit more thought about what to do about
deeply quoted strings?

Scheme language solves this problem by requiring all
quotes within strings to have the escape character
immediately preceding the quote ie ^" or \" as it is in
Scheme.

-- An Aside --------

What is the origin / choice / inspiration for the use of
the ^ as the escape character as opposed to \ which is used
in a lot of other languages?

My view is that ^ is much more pretty and unobtrusive.

-- End of Aside -----

However requiring quotes to be escaped can be a real
bummer, especially with deep nesting of quotes.
One way around this is to use a string terminating sequence
and that is why I chose the quote-dot ". and brace-dot }.
combination as string terminators. That way any quotes
or braces within the strings are treated as characters
and don't need to be balanced nor escaped. If you don't like
the dot then perhaps we can look at alternative suggestions
for string terminating character(s) sequences, don't worry
as it's only syntax 8-) , however anything we do choose
should be distinctive, elegant & unobtrusive ;-)

Another idea that might be possible is keeping strings
as is with braces & quotes and requiring unicode strings
to have a prefix u" or u{ to identify them as unicode
however i don't think that's very pretty nor elegant.

Again with immutable-string! and immutable-block! I like
the suggestion of the prefix dot options ." .{ .[ as I
think the dot / period is unobtrusive & elegant but also
makes a statement that these values are distinct & constant!
This will be their value period! hence they are immutable.
What do you think? again it's only syntax so Iam open to
suggestions. 8-)

About based numbers, in PRIMO the current REBOL datatype
binary! will become binary-string! as that more accurately
represents what they are. Sure issue! can still represent
hexadecimal values as well as 2#{} 16#{} and 64#{} binary
or indeed as you say binary-string! n#{} could represent
and number base for 'n as long as there are sufficient
digits and characters to represent a viable number / value
correspondance, so in that repect I like your idea and think
that binary-string! should be given those abilities.

However my hex!, binary! & octal! are NUMERIC values and
are stored as 32bit ( or any other number of bits ) values
like integer! are. They are NUMERIC values and can be used
just as easily with aritmetic and logic functions without
conversion from any-string! to number! types as is currently
required with REBOL hex issue! or Binary! types which cannot
be added, multiplied etc without prior number conversion to
integer!

>> number? #FF
== false
>> number? 16#{FF}
== false
>> any-string? #FF
== true
>> any-string? 16#{FF}
== true
>> add #FF #FF
** Script Error: add expected value1 argument of type: number
pair char money date time tuple
** Near: add #FF #FF
>> add 16#{FF} 1
** Script Error: add expected value1 argument of type: number
pair char money date time tuple
** Near: add #{FF} 1
>> add to-integer #FF to-integer 2#{11111111}
== 510

In my proposals hex!, octal! & binary! are NUMBER! values
and can be used by the arithmetic & logic functions, it is
only their datatype! value which causes them to be displayed
in their appropriate NUMBER format.

Consider the the integer number! 1 in my suggestions these
would be the possible numeric formats....

1 integer!
1 decimal!
1b binary! ; 1bin - more visually distinctive?
1o octal! ; 1oct - ditto ?
1h hex! ; 1hex - ditto ?
1/1 ratio!
1+0i complex!
1i imaginary!

I've not totally made up my mind about the final display
format for hex!, octal! & binary! - opinions please?
the 1b 1o & 1h formats are those used in Scheme language
but maybe 1bin 1oct & 1hex is more visually distinctive?
and maybe a more definite sequence for the parser to
identify?

Again I'm canvassing for opinions as to which is more
preferable & elegant syntactically?


About garbage collection, I've bookmarked a few pages and
resources on the web a while ago und put them in my "FUTURE"
study folder as I've only got a vague conceptual understanding
of this topic so any help or advice on this matter would be
greatly appreciated! LADISLAV seems to have thought indepth
about what is happening and perhaps we should investigate his
ideas further.

About Memory-address! datatype, I look for PRIMO to one day
have the features of the Languages I like best which are
REBOL, MIT Scheme & F-PC FORTH. F-PC Forth is a fantastic
forth environment with an interpreter, native code assembler
compiler & disassembler / debugger as well as it's own
editor, source & help.

It gives the programmer access to all system levels and
resources at either the native code or FORTH code level,
however with this power comes the need for caution and care
not to violate the registers & memory that F-PC uses for
it's own purposes. It doesn't have garbage collection
built in although I do believe that people have implemented
garbage collection routines for FORTH F-PC.

I know this raises many issues from a practical and security
perspective, however the power to "use with care" and the
ability to have full access to any system feature or resource
is more desirable in my view than artificial limits or
constraints.

It is only by being fully open and changeable at ALL levels
can the system truly adapt & survive to meet unforeseen future
needs, otherwise it is a CLOSED system and sooner or later it
will collide with it's own limitations or restrictions.

Yes this might necessitate system specific implementations or
perhaps different types general purpose & system specfic PRIMO's
but that is a good thing in my opinion rather than a one size fit's
all solution.

Let me know what you think about all this, and MARCUS I would
especially like to see some examples of you datatype implementation
proposals.

cheers,

Mark Dickson