Re: Pondering what rationale behind record type

[Shark8 <onewingedshark@gmail.com>]

On May 11, 2:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Tue, 10 May 2011 19:28:16 -0700 (PDT), Shark8 wrote:
> > On May 10, 7:50 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> >> What is the reason to name statements?
>
> > Simple: to aid in readability.
> > I have a few rather deeply nested items where I'm tokenizing
> > PostScript
> > (due the rules of the language) and it is handy to have things like
> > -- Case C, When C '<' =>
> > Read_Character( C, Input );
> > HANDLE_LT: -- less than
> > if C = '<' then
> >  Return Dictionary_Type;
> > elsif C = '~' then
> >  Return String_Type;
> > else
> >  Unread_Character( C, Input );
> >  Return -- I forgot what the last case, just '<', was...
> > end if HANDLE_LT;
>
> The above should have been a "case", or better matching the input against a
> token table with semantic callbacks doing things.
>
> > There's even a few in blocks where I handle things like
> > names ['identifiers'] vs. numbers; the PLRM defines a name
> > as a string of "regular characters which cannot be interpreted
> > as a string." This means that 23E4 is a number while 24F4 is
> > a name as are $4, 2i3, @, 2^4 and so forth.
>
> That is semantic analysis to me. No need to burden parser with that. You
> parse 23E4 as a token and later interpret it as an identifier or number.

True, it is semantic analysis.
The way I have it set up is this case structure is inside my
tokenizer;
the tokenizer may or may not be on the same machine as the parser
itself.

One of the reasons that I'm forced to use if-statements in the cases
for
the various constructs is because some of them are dependent on state:
Strings, for example are delimited with parentheses, BUT may contain
balanced pairs or be escaped out.

So, (Here we are (nowhere).) is equal to the Ada String "Here we are
(nowhere)."
A quick/easy "go to the next closing paren" will produce incorrect
results,
just as it would in the string (:/)) which is equal the Ada String
":)".

Finally, the case I was writing from memory, the [first] less-than can
be:
1 - The first part of the "<<", a Dictionary, which is self-
delimiting.
2 - The first part of the "<~", which is a Hex-encoded String (IIRC).
3 - I still can't remember what just '<' was...

> > It REALLY does help in sorting where you are in the decoding.
>
> I don't think that large "if"s is a good style. No names may help that.
> BTW, in your case "then", "else", "elsif" must carry the name of the "if"
> they belong.

I don't either; but the PLRM does describe the parser as consuming the
characters/tokens from the input and then producing the proper
object*.

Also, I want to have the ability to have the parser a separate
component,
likely a server on a remote-machine handling multiple clients, and
that
imposes its own constraints as well.

* Not as in OOP-Object, but as in component... though you could use
OOP.