Implement mutable/immutable variables #17

New Issue

There is no sub-scenario in which it would make sense for scenarios 1 or 2 to reject an assignment based on their type. It would absolutely make sense to consider mutability when determining (within the analyzer) whether an expression is a location expression or not. However, this would not allow indexing into an immutable composite/aggregate type. Perhaps it would be wise to create a mutability testing function that is only used in assignment instead.

This mechanism could also be used for enumerated constants.

The only scenario in which mutability matters is in assignment statements, as there are a fixed amount of assignment scenarios: 1. Assignment statements 2. Argument passing to a function or method 3. Argument passing to a language construct There is no sub-scenario in which it would make sense for scenarios 1 or 2 to reject an assignment based on their type. It would absolutely make sense to consider mutability when determining (within the analyzer) whether an expression is a location expression or not. However, this would not allow indexing into an immutable composite/aggregate type. Perhaps it would be wise to create a mutability testing function that is *only* used in assignment instead. This mechanism could also be used for enumerated constants.

sashakoshka commented

2024-04-09 12:47:43 -06:00

This would not require any refactoring of the analyzer which is good because oh god

sashakoshka removed a dependency 2024-04-09 12:47:49 -06:00

#67 Refactor semantic analyzer

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: fspl/fspl#17