Persistent Immutable Data Structures?

With all the awesome discussion about the future of lucee and the language.
I would like to raise to the surface a slightly mentioned topic in one of
the other groups.

What would it take to have first class support for Persistent Immutable
Data Structures in the language?

I recommend the wikipedia article
http://en.wikipedia.org/wiki/Persistent_data_structure for a refresher on
persistent immutable data structures if anyone feels the need.

Here is the kind of thing I am thinking of.

arr = ^[5,6,7]; //creates a persistent immutable array
arr1 = arrayAppend(arr,8) //
arr2 = arrayDeleteAt(arr, 2) // doesn’t change the array arr but arr2 gets
a new copy without the 2nd element.
arr = arr :+ 8; // We could copy scala syntax to append or prepend new
elements to the array.

Structs could be have similarly immutable counterparts. The only problem I
have is that those functions seem to have to work differently depending on
whether the data structures are mutable or immutable which seems like such
a bad idea.

Here is a library that could be used under the hood.

I am wondering if I am alone in wanting immutable data structures in the
language?

As someone who uses PIDS all day, every day in Clojure, I’d love to see them in Lucee as an option. They help avoid a lot of mistakes (your data can’t “accidentally” get stomped on by another thread or another piece of code), you can share data between threads safely (which makes concurrent code easier to write).

Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/

“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Feb 19, 2015, at 12:24 PM, Colby Litnak <@Colby_Litnak> wrote:

I am wondering if I am alone in wanting immutable data structures in the language?

Yes I would like this a lot!

The only problem I have is that those functions seem to have to work
differently depending on whether the data structures are mutable or
immutable which seems like such a bad idea.

Member functions return different values already.

ArrayAppend(arr, 1) // returns true
arr.append(1) // returns arr

So this might be a possible way around this, arr.append could return a
copy. ArrayAppend should throw an exception then.

Here is the kind of thing I am thinking of.

arr = ^[5,6,7]; //creates a persistent immutable array
arr1 = arrayAppend(arr,8) //
arr2 = arrayDeleteAt(arr, 2) // doesn’t change the array arr but arr2 gets
a new copy without the 2nd element.

I think this is a terrible example. arrayDeleteAt on a non-persistent array
returns a boolean, but on a persistent array it returns a copy?

Structs could be have similarly immutable counterparts. The only problem I

have is that those functions seem to have to work differently depending on
whether the data structures are mutable or immutable which seems like such
a bad idea.

On arrays that is a bad idea as well.

JochemOn Thu, Feb 19, 2015 at 9:24 PM, Colby Litnak wrote:


Jochem van Dieten
http://jochem.vandieten.net/

That it returns a boolean in the first place was a stupid language decision (thank you Allaire?). It would be better if all the array functions returned either the (modified) array — or the element in question for a read, obviously.

The interesting question would be whether this sort of silly inconsistency could be fixed for .lucee script files, leaving the borked behavior alone in the .cfm/.cfc files?

Sean Corfield – (904) 302-SEAN
An Architect’s View – http://corfield.org/

“Perfection is the enemy of the good.”
– Gustave Flaubert, French realist novelist (1821-1880)On Feb 20, 2015, at 3:47 AM, Jochem van Dieten <@Jochem_van_Dieten> wrote:

I think this is a terrible example. arrayDeleteAt on a non-persistent array returns a boolean, but on a persistent array it returns a copy?

The interesting question would be whether this sort of silly inconsistency
could be fixed for .lucee script files, leaving the borked behavior alone
in the .cfm/.cfc files?

The important question is whether this should be fixed based on the
file extension.

JochemOn Fri, Feb 20, 2015 at 5:47 PM, Sean Corfield wrote:


Jochem van Dieten
http://jochem.vandieten.net/

Ruby has ‘freeze’ which is quite nice. So you could have something like:

arr = [5,6,7]
arr.freeze()

http://rubylearning.com/satishtalim/mutable_and_immutable_objects.htmlOn 20 Feb 2015 17:40, “Jochem van Dieten” <@Jochem_van_Dieten> wrote:

On Fri, Feb 20, 2015 at 5:47 PM, Sean Corfield wrote:

The interesting question would be whether this sort of silly
inconsistency could be fixed for .lucee script files, leaving the borked
behavior alone in the .cfm/.cfc files?

The important question is whether this should be fixed based on the
file extension.

Jochem


Jochem van Dieten
http://jochem.vandieten.net/


You received this message because you are subscribed to the Google Groups
“Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/CABPCP-3twQA7wQxXYmvg_DpGCimNXXrbMLJ%2BobNn74iUsFKirg%40mail.gmail.com
https://groups.google.com/d/msgid/lucee/CABPCP-3twQA7wQxXYmvg_DpGCimNXXrbMLJ%2BobNn74iUsFKirg%40mail.gmail.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

If the idea behind .lucee is to break with the bad rep ( and bad practices ) of CFML, then these kinds of things should be fixed in .lucee files. .cfc/.cfm files are going to maintain compatibility with CFML, so there is no reason to maintain backwards compatibility with CFML’s funky inconsistencies.

On a broader note, I like the idea of Lucee (the product) as a programming engine on the JVM where you can create and execute arbitrary scripting languages. So far the idea is to have essentially two dialects of script with a root in CFML, but in theory could Lucee not support any number of dialects based on file extension? Very interesting possibilities…On Feb 20, 2015, at 9:40 AM, Jochem van Dieten <@Jochem_van_Dieten> wrote:

On Fri, Feb 20, 2015 at 5:47 PM, Sean Corfield wrote:
The interesting question would be whether this sort of silly inconsistency could be fixed for .lucee script files, leaving the borked behavior alone in the .cfm/.cfc files?

The important question is whether this should be fixed based on the file extension.

Jochem


Jochem van Dieten
http://jochem.vandieten.net/


You received this message because you are subscribed to the Google Groups “Lucee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CABPCP-3twQA7wQxXYmvg_DpGCimNXXrbMLJ%2BobNn74iUsFKirg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.