World: r3wp

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, ...

The text is not a function. The *handler* for the text is a function.

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

TRANSCODE calls the action. I am talking about internal code here.

And it's not text - bug#864 proved that.

yes, I understand, there is a constructor (there has to be one), 
but the "#[...]" text is not a constructor, just data for a constructor

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.

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)

Well, the function "somewhere else" is all that I have been talking 
about, not the lexical form.

BTW, what do you think about the END! datatype? is there really a 
reason, why it has to be "exposed"?

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.

There are other internal datatypes, like handle! and frame!.

I do know one use for the END! datatype, but am not sure, it should 
be "exposed" this way, taking into account, that it is an "implementation 
detail" in fact. The same applies to handle! and frame! or e.g. the 
symbol! datatype n earlier interpreter versions.

You are prejudging on what is exposed: Most of the code hasn't been 
modularized yet :)

aha

yes, that is why I wondered

Same about Pekr's complaint earlier about LOAD-PLUGIN. We aren't 
prematurely modularizing the code so as to avoid setting up artificial 
barriers. It is better to let the code grow and see where the natural 
bondaries are. Alpha :)

do/next matters to me, but, I don't count for language features (Carl 
put me in the 0.1% basket ;-)


What I would like is a "break out"of a block much like throw, that 
allows me to re-enter even in nested blocks.

Continuations, basically. Sorry :(

e.g.   pos: reduce/do/try/...  [ some code [ nested [ and then some 
[ break! some more more ] more ] really ] more ]

And then: "into" pos

I think a closure over the evaluation with an "into" would do it. 
It is easy to see parse with into do this.

That's a continuation.