r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Henrik
3-Jun-2009
[14928]
And it's important to have as many datatypes as possible for dialects.
Pekr
3-Jun-2009
[14929]
I know. I just thought, that money (better let's call it currency), 
is just another unit ...
BrianH
3-Jun-2009
[14930]
$ is used as a sigil of money in many countries, not just the US.
Pekr
3-Jun-2009
[14931x2]
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.
Henrik
3-Jun-2009
[14933]
In school, units were always encased in [], such as 5 [m / s]. I 
think it's possible to do something similar in REBOL.
BrianH
3-Jun-2009
[14934]
More complex
 = "like R2". He was asking about restoring the unit prefix.
Henrik
3-Jun-2009
[14935]
could a serialized item be considered its own datatype?, such as 
#[none]
Ladislav
3-Jun-2009
[14936]
I do not understand your question
Henrik
3-Jun-2009
[14937]
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.
Pekr
3-Jun-2009
[14938]
Henrik probably wanted to introduce new form to REBOL's parser: 100[m 
/s]
BrianH
3-Jun-2009
[14939]
There are a few serialized keywords, but the rest are constructors.
Pekr
3-Jun-2009
[14940]
but then he realised, that we have already #[none] for serialisation 
... but I can be wrong ...
Henrik
3-Jun-2009
[14941]
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.
Pekr
3-Jun-2009
[14942]
or ~[m / s]
Henrik
3-Jun-2009
[14943]
good one
Pekr
3-Jun-2009
[14944]
Will something like that work with user types? Can I define its "lexical 
form" (?) so that REBOL parser would accept that?
BrianH
3-Jun-2009
[14945]
User types won't be able to affect the lexer.
Pekr
3-Jun-2009
[14946]
So how REBOL identifies my user type?
BrianH
3-Jun-2009
[14947]
MAKE or serialized forms, I expect.
Ladislav
3-Jun-2009
[14948]
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"
BrianH
3-Jun-2009
[14949]
They are constructors internally, as you describe - try doing a bad 
one and read the error message.
Pekr
3-Jun-2009
[14950]
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?
BrianH
3-Jun-2009
[14951]
And they aren't textual representations - the data inside the serialized 
representation is REBOL data, not raw text.
Ladislav
3-Jun-2009
[14952x2]
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
BrianH
3-Jun-2009
[14954x2]
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.
Ladislav
3-Jun-2009
[14956]
Wikipedia: Constructor (computer science), a special method used 
in object oriented programming which puts the object's members into 
a valid state.
BrianH
3-Jun-2009
[14957x2]
In REBOL, methods are called action! functions. Same principle, different 
implementation.
MAKE and TO are constructors too.
Ladislav
3-Jun-2009
[14959]
MAKE and TO: they can be called "methods", since they are functions, 
but #[...] is something totally different, and it surely isn't "a 
method"
BrianH
3-Jun-2009
[14960]
Internal, remember?
Ladislav
3-Jun-2009
[14961]
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
BrianH
3-Jun-2009
[14962x2]
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.
Ladislav
3-Jun-2009
[14964]
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
BrianH
3-Jun-2009
[14965x2]
Except the deserialization actions are exposed, indirectly. Not as 
action! functions - they are called by TRANSCODE, TO-BLOCK, ...
The text is not a function. The *handler* for the text is a function.
Ladislav
3-Jun-2009
[14967x2]
yes, but then the methods are Transcode, To-block, etc. the #[...] 
texts are only data for them
so, the distinction is, that "#[...]" actually is data (argument/arguments) 
for a constructor, not a constructor
BrianH
3-Jun-2009
[14969x2]
TRANSCODE calls the action. I am talking about internal code here.
And it's not text - bug#864 proved that.
Ladislav
3-Jun-2009
[14971]
yes, I understand, there is a constructor (there has to be one), 
but the "#[...]" text is not a constructor, just data for a constructor
BrianH
3-Jun-2009
[14972x2]
Ladislav, if you think that I am saying that the lexical form #[...] 
is a function call, you are wrong. I am saying that the processing 
of that lexical form is handled by an internal function call that 
constructs a value of a particular datatype. That is what I have 
always beenn saying.
And since then I have been trying to clear up that misunderstanding.
Ladislav
3-Jun-2009
[14974]
yes, that is correct, of course. What I mean by saying, that #[...] 
is not a constructor is, that the function is "somewhere else" (in 
C or internal Rebol code, I do not exactly mind in this case)
BrianH
3-Jun-2009
[14975]
Well, the function "somewhere else" is all that I have been talking 
about, not the lexical form.
Ladislav
3-Jun-2009
[14976]
BTW, what do you think about the END! datatype? is there really a 
reason, why it has to be "exposed"?
BrianH
3-Jun-2009
[14977]
There is a reason to reserve it, but not expose it per-se. It would 
need to be used by internal code and a lot of that internal code 
is written in REBOL in R3. From what I know about blocks (minimal), 
it seems like the nul character for C strings, but less required.