Prolog uses IMMUTABLE variables.
My question is : when you “extend” a list , internally the Origin list get copied as a new list OR it is just extended.
What I want to understand is how exactly/specifically the variable immutability helps Prolog ?
And what is the mechanism ?
Let me explain why I ask this. Currently learning Rust and it has a complex semantics on handling mutability and scope , which is rather interwoven.
I was thinking if I follow Prolog like IMMUTABILITY semantics can work in place of using the full Rust-move|borrow semantics?
Think of it as a copy when you write Prolog code. The actual way it is done internally can vary for various reasons, e.g. implementer design, hardware or virtual machine instructions the code is running on, underlying data structures used to implement the variables, etc.
Allows Prolog to backtrack.
I don’t know Rust so can’t help you with that.
However in learning IMMUTABILITY I personally found that learning F# which is a functional language and has some very simple syntax and makes extensive use of immutable variables was very helpful. There are other functional languages that have a nightmare of boilerplate for the syntax and I run away from them.
a) unlike in imperative languages, including those with immutability, variables in Prolog are logic variables – they are bound only once because they represent (bound) relations
b) change in relational languages like in Prolog is really a relational expression.
By default, everything is immutable in Prolog. (The exceptions are mainly here, and are generally avoided, or wrapped in something that makes them appear immutable, such as distinct/1.)
In this respect, Prolog is like functional programming languages, such as Haskell, OCaml, etc. In general, if two things look the same (using write_canonical/1), then they are the same.
Logical variables are simple place-holders for values that haven’t yet been computed – once set, they can’t change (although backtracking can undo the binding, allowing a different value that satisfies the computation).
There are also “attributed variables”, which can be use to add constraints to variables – they’re still immutable, but the range of possible values can be narrowed as constraints are added.
(Under the covers, there are many areas of non-immutability, such as with tabling.)
There’s one other area of non-immutability – assertz/1 and retract/1, for predicates.These bring in the possibility of non-monotonic reasoning.
I am likely nitpicking here – or not fully understanding – but, somehow I feel that despite immutability looking the same, Prolog is not like functional programming languages in this respect.
Immutability in functional languages is to avoid overwriting memory cells as part of transformations that functions perform – so, instead, copies are provided and used as part of the transformations.
Whereas, in Prolog immutability is inherently part of what logical variables are – and is part of the descriptive device underpinning how to solve problems logically and relationally.
I guess I am trying to give voice to my own misunderstandings when I first picked up Prolog to work more extensively with it.