Schemacode: regions

[cardillan]

A region is a group of blocks arranged into a rectangular shape, which can be placed into the schematic as a single block. A region can be either named or unnamed. Named regions can be placed several times into the schematics. Both named and unnamed regions can be combined with the block array syntax to create a repeating pattern in the schematics.

Proposed syntax:

schematic
    // A named region
    myregion = region
        switch1: @switch at (0, 0)
        message: @message at (1, 0)
        memory#: @memory-cell at (2, 0)
                 @micro-processor at (3, 0) processor
                    links
                        switch1
                        message
                    end
                    mindcode = ...
                end         
    end

    first: myregion at (0, 0)
    second, third: myregion at (0, 1) * (1, 2)
    
    // An anonymous region
    fourth#: region
        switch2: @switch at (0, 0)
        message: @message at (1, 0)
    end at (0, 3) * (2, 2) facing north
    
    @micro-processor at (-1, 0) processor
        links
            first.switch1 as switch1    // at 0, 0
            second.switch1 as switch2   // at 0, 1 
            third.switch1 as switch3    // at 0, 2
            fourth1.switch2 as switch4  // at 0, 3
            fourth2.switch2 as switch5  // at 1, 3  (due to rotation!)
            *.memory# as cell#
        end
    end
end

Notes:

• Region is always rectangular and its size is automatically determined by the blocks it contains.
• Some tiles within a region may be left empty. Other blocks may be placed onto the empty tiles from the outside of a region.
• A named region may be invoked several times.
• An anonymous regions generally only make sense to be used in the context of a block array. Alternatively, unnamed regions allow encapsulation of link names (link patterns can also be used for that though).
• The schematic itself exists as an unnamed top-level region.
• Regions can be nested.
• Named regions must be declared within the schematics before being used (prevents recursion)
• Region creates a namespace for labels.
  • A labeled region creates a new namespace available under its label: first.message addresses the message block in the first region.
  • An unlabeled region creates a new namespace which can't be addressed. Labels inside the region aren't accessible outside the region.
  • Links names are resolved using the namespace of the current region. When not matched, the outer region is searched (recursively).
  • Every label can be accessed by its full name, from any region.
• Link pattern matching works on region names:
  • first.* matches all blocks in the first region.
  • a.b.* matches all blocks in the region b nested within the region a.
  • *.b.* matches all blocks in the region b nested within any region (this will probably only work with label arrays).
  • When automatically converting a label into a link name, the region names are stripped as well as a prefix.
• When placing a region, it can be rotated using facing. east is the original orientation. north, west and south are rotated counter-clockwise by 90, 180 and 270 degrees respectively.
• Labels are assigned to regions in block arrays using the usual rules for label allocation.
  • Label arrays can be used with regions (if we can make it work)

Label arrays should be made available in processor link specification as well, allowing, for example:

schematic
    message#: @message at (0, 1) * (1, 4)
    @micro-processor at (1, 0) * (4, 1) processor
        links
            message# as message1
        end
    end
    
    @micro-processor at (0, 0) processor
        links
            message#
        end
    end
end 

(Not possible with current implementation.)

[cardillan]

Further thoughts on regions:

The area of the region will always start at (0,0) and end at the highest x and y coordinates of any occupied tile (but always at least 1x1). This means the region may contain empty rows or columns (on the bottom/left), or contain blocks outside its area (on tiles with negative coordinates). This will allow using regions as block arrays with space in between blocks, or non-rectangular spaces to boot:

region
    @memory-cell at (-1, 1)
    @switch at (0, 2)
end at (1, 0) * (4, 2)

This will create blocks in this pattern ([c]ell, [s]witch) - at least if I'm not mistaken:

 ssss
cccc

 ssss
cccc

Placing a single, configured block within a region allows to repeat the block including its configuration. This will be particularly useful for processors. Furthermore, if a region consists of a single block, a label assigned to the region will be actually assigned to the block, and no namespace for the region will be created.

Regions may overlap if their blocks do not overlap. The checks will be done after all block positions are resolved.

New keywords will be added: left, right, up and down. They will refer to the tile neighboring the last placed block in the given direction. Therefore, this will be possible:

@memory-bank at (0,0)
@switch right           // resolves to (2, 0)
@memory-cell up         // resolves to (2, 1)
@message down + (1, 0)  // resolves to (3, 0)