How Pattern C-struct could look like

[kblomqvist]

See initial structure: https://github.com/docopt/docopt.c/wiki#new-c-struct-ideas

Let's keep the discussion and brainstorming here rather than in wiki. Ideas can be added to wiki afterwards.

[ffunenga]

I'll point out some details I've noticed and propose some alternatives (doesn't mean they are better, they are just ideas on the table):

• struct Pattern
  • Why don't we separate this struct into Leaf and Branch?
  • Why do we need type None? (I know it is used to terminate the Elements array). Couldn't we have an integer specifying the number of elements in the array?
  • Instead of Leaf.payload perhaps Leaf.object or Leaf.element would be simpler.
  • Instead of Branch.container maybe Branch.children would be better

[EDIT] Check out this example: https://gist.github.com/ffunenga/5744034

This doesn't compile in C++. The problem is the union inside the struct

[keleshev]

Seems like a reasonable solution. How do you plan to allocate Child *children;?

[keleshev]

Oh, right, we know number of children while we generate code, so we can allocate enough of them. That's better than having a linked list, or separate type for each parent.

[keleshev]

Some questions;

1. .object.branch = is C99 only, isn't it? If it is—we can just use comma-separated values for C89, right?
2. what's the problem with union inside struct in C++?

[kblomqvist]

1. Yes
2. The problem is not the union inside the struct but a compound literal used as an initializer at line 64. These are not supported by C++.

[ffunenga]

I've added a new section to the wiki: https://github.com/docopt/docopt.c/wiki#non-recursive-similar-to-pythonic-approach

It might be easier to think about the required structs after defining the algorithm.

[ffunenga]

I think I've found a problem that complicates things in STPA...

In python, it's simple to make a list and append things to it, since the the garbage collector will take care of it in the end (see here). So whenever an argv's element is not recognized as a Command (i.e. a possible Argument), we just append it to the list as an Argument(None, tokens.move()) (see here).

In C, this approach (list appending) is implemented by malloc'ing unidentified Arguments to a temporary list.

We need to decide what is preferable:

• to have the sub-pattern's state-machines awaiting for values (NR-STPA) or
• to malloc unidentified Arguments into a temporary list and identify them after, using the pattern tree (STPA).

What should the docopt.c algorithm do when an unidentified Command is found in argv?

---

It just occured to me now, but can an Argument have the same value as a Command?

Usage:
    program ship new <name>

what should happen if I want to name a new ship in this program with the name "ship":

$ ./program ship new ship

The pattern seems respected because the order and number of elements are correct. Should this work @halst?

[keleshev]

./program ship new ship is correct. Note that parse_argv in python does not return commands. It returns only options and (positional) arguments. Later it is decided which positional arguments are commands and which are not.

I don't have an immediate opinion or solution to malloc problem. I would really love to avoid malloc at all. But we don't know argv length before run-time. So maybe we could avoid parse_argv and work directly on argv, maybe modifying some of it in-place? Maybe match directly on it, not on a parsed version?