View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000291 | LDMud | LPC Compiler/Preprocessor | public | 2004-11-26 23:55 | 2022-10-06 19:47 |
| Reporter | Assigned To | fufu | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | unable to reproduce | ||
| Summary | 0000291: Implement a generic empty mapping | ||||
| Description | Short: Distinguish between generic and specific empty mappings From: Lars Date: 2002-05-07 Type: Feature State: New The '([])' should be a dedicated 'generic' empty mapping with no specific width. The empty mappings produced by m_allocate() have a fixed width. This makes a difference for functions like mapping additions which check the mapping width. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
I think this is mostly straightforward. But how should lvalues based on such a generic mapping work? mapping m = ([]); m["",1] = 42; // Currently: Illegal sub-index 1, mapping width is 1. The safe option is to keep the error; the alternative would be to expand the mapping when the lvalue is created. Neither of these options would cope with using mapping m = ([]); m[k, 0] = value0; m[k, 1] = value1; in place of m_add. |
|
|
I don't know how we could make the last example work. An undetermined empty mapping cannot stay this way when data is added. So m[k,0] = value0; would make it a mapping of width 1, and therefore the second assignment would fail. I don't have a firm opinion on whether indexing operations with a sub-index > 0 should be allowed on undetermined empty mappings. If we take 'generic' or 'undetermined' seriously, then such operations might be valid. |
|
|
I'll keep this one. It still looks pretty easy to implement if we want it: Allow the num_values entry of a mapping to be -1 (indicating the generic mapping) provided that num_entries is 0 *and* both the hashed and condensed parts are NULL. This should work out fine because all operations that create those parts add entries, at which point the mapping width will be known, and stay fixed from that point onward. Oh, another question is what widthof(([])) should be. Conservatively it should be 1, but -1 is another option and would provide a way for the mudlib to tell generic empty mappings and empty mappings with specified width apart. |
|
|
Mhmm, what would be the benefit of having this in contrast to the historic current state of "([]) is a mapping with width 1"? I think, at this stage it complicates matters and I think, having an undecided state is rather more error-prone... |
|
|
Well, empty mappings play a double role; they have a width, but that width is ignored when they are involved in addition, so they are treated as generic in those contexts. Having a dedicated generic empty mapping would allow checked addition... ([:1]) + ([:2]) would then be an error, while ([]) + ([:2]), ([:1]) + ([]), and ([]) + ([]) would continue to work. LPC code could then be incrementally be switched from a style that uses generic mappings to a style that uses empty mappings with a specified width. Other than keeping the status quo (obviously that option is on the table), there's a third direction we could take this: Eliminate the generic treatment of empty mappings completely, making addition check that the width of mappings is compatible in all cases, even for empty mappings. Unfortunately this is hard to identify statically; there is no incremental way of updating existing code to cope with the change. Puzzle: what is widthof(([:2]) + ([:3]))? |
|
|
Closing this, as this value-add is not that much compared to the effort to implement that. There are some pitfalls regarding compatibility (saving and restoring those mappings). Instead we are thinking about eliminating the special treatment of empty mappings completely for LDMud 3.7. If you want to continue working on this, please reopen it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-26 23:55 |
|
New Issue | |
| 2008-08-04 20:58 | fufu | Status | new => assigned |
| 2008-08-04 20:58 | fufu | Assigned To | => fufu |
| 2008-08-04 20:59 | fufu | Relationship added | related to 0000475 |
| 2021-04-08 22:15 | fufu | Note Added: 0002574 | |
| 2021-04-08 22:30 | Gnomi | Note Added: 0002575 | |
| 2021-04-08 22:44 | fufu | Note Added: 0002578 | |
| 2021-04-09 07:28 | zesstra | Note Added: 0002581 | |
| 2021-04-10 14:31 | fufu | Note Added: 0002582 | |
| 2022-10-06 19:47 | Gnomi | Status | assigned => closed |
| 2022-10-06 19:47 | Gnomi | Resolution | open => unable to reproduce |
| 2022-10-06 19:47 | Gnomi | Note Added: 0002694 |
