World: r3wp

Some ppl still confuse what I am proposing. The same goes for Carl. 
I don't want to remove anything. I just want to change the really 
bad name. I refuse to accept the fact, that such general mechanism 
as BCD is linked to as ugly name as money! is. So what I want is 
- either another general BCD datatype, or - rename money! to unit! 
and it could work that way:

g$100
v$100
km$100
USD$100

Of course I am not sure it is flexible enough, as how would I express 
e.g. km/h?

Calling it "money" makes sense when you consider that the only available 
character for the literal representation is $.

renaming it sounds very much like removing it.

I have to be really stupid, or I really can't understand, how renaming 
something = removing something? So are we going to remove 'map, just 
because we are going to rename it to 'map-each?

also tieing a unit to a number directly might limit the applicability 
of unit calculations as used in physics and symbolic math.

I don't want to call it "unit!" because the type would be really 
poor for that, and we don't want to reserve the word "unit" for a 
poor implementation of the idea, especially when we have user-defined 
datatypes.

BrianH: then think of $ as a sign of measure (that was another name 
for money, but unit is shorter and more to the point). Why is file 
represented by % sign then? It has nothing in common with percentage 
= $ has nothing in common with money. Maybe in US.

Pekr, renaming a function is not the same as renaming a datatype. 
You lose functionality and gain something specifically different. 
When renaming a function, you don't lose anything.

File is being represented by % since that is what was left.

Henrik - how can you loose functionality by just renaming it? :-)

Pekr, you don't have money anymore. That's the loss.

And it's important to have as many datatypes as possible for dialects.

I know. I just thought, that money (better let's call it currency), 
is just another unit ...

$ is used as a sigil of money in many countries, not just the US.

OK, so give me BCD! type then. I will not do make money! just because 
I want some precision. That reads badly ...

IIRC there was a blog what to do with money! datatype, and if the 
datatype should be more "complex". That is still not resolved.

In school, units were always encased in [], such as 5 [m / s]. I 
think it's possible to do something similar in REBOL.

More complex
 = "like R2". He was asking about restoring the unit prefix.

could a serialized item be considered its own datatype?, such as 
#[none]

I do not understand your question

I'm not sure it makes sense anyway. :-) I guess it's about how the 
scanner interprets certain characters and from that works out the 
datatype, and what limitations there are in detection.

Henrik probably wanted to introduce new form to REBOL's parser: 100[m 
/s]

There are a few serialized keywords, but the rest are constructors.

but then he realised, that we have already #[none] for serialisation 
... but I can be wrong ...

Pekr, yes, although [] directly, won't work. I'm assuming that we 
could basically do something like ![m / s] or &[m / s] and have that 
work as a datatype.

or ~[m / s]

good one

Will something like that work with user types? Can I define its "lexical 
form" (?) so that REBOL parser would accept that?

User types won't be able to affect the lexer.

So how REBOL identifies my user type?

MAKE or serialized forms, I expect.

constructors: I guess, that it is actually "nonstandard" to call 
#[...] representations "constructors", since they actually aren't 
"methods used to create instances of...", in fact, they actually 
aren't "methods", but rather "textual representations"

They are constructors internally, as you describe - try doing a bad 
one and read the error message.

BrianH: but I somehow have to distinguish usertype from e.g. decimal? 
So how do I do it? And how does REBOL's interpreter know it is mytype? 
How do I match it in parser for e.g.? Any example?

And they aren't textual representations - the data inside the serialized 
representation is REBOL data, not raw text.

the error message is: "** Syntax Error: Invalid construct -- #[**" 
how does that tell it is a method?

and, BTW, "construct" and "constructor" does not have the same meaning 
for me

Between that and conversations with Carl, it has become apparent 
that deserialization is done on a type-specific basis, and that the 
supported types have internal chunks of code that handle the data 
in the representations. You are being too specific in your definition 
of "constructor" - even in the OOP languages it means "something 
that constructs".

The internal code is something like MAKE or TO - type-specific.

Wikipedia: Constructor (computer science), a special method used 
in object oriented programming which puts the object's members into 
a valid state.

In REBOL, methods are called action! functions. Same principle, different 
implementation.

MAKE and TO are constructors too.

MAKE and TO: they can be called "methods", since they are functions, 
but #[...] is something totally different, and it surely isn't "a 
method"

Internal, remember?

there is nothing like "internal" from a user's POV, anything "internal" 
should be invisible, that is why I honestly don't understand, why 
the END! datatype is exposed

Not all the actions are exported as action! functions - some are 
only called by native code, like the action that handles function 
eval.

I was talking about an internal action, not something exposed.

moreover, the #[...] constructs are actually executed by the LOAD 
function (or maybe Transcode,...) internally, which may call whatever 
functions it likes to construct any specific datatype represented 
by the discussed #[...] text, but this does not make the "#[...]" 
text a function, anyway

Except the deserialization actions are exposed, indirectly. Not as 
action! functions - they are called by TRANSCODE, TO-BLOCK, ...