World: r3wp
[!REBOL3-OLD1]
older newer | first last |
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. |
older newer | first last |