eval(repr(x)) == x

[phil hunt]

On Mon, 28 Jan 2002 09:53:55 +0000, Jonathan Hogg <jonathan at onegoodidea.com> wrote:
>On 27/1/2002 20:26, in article slrna58oja.4cd.philh at comuno.freeserve.co.uk,
>"phil hunt" <philh at comuno.freeserve.co.uk> wrote:
>
>> I once designed a language whose main feature was that this
>> was true for all x.
>> 
>> As a consequence, all data was trivially serializable.
>
>Haskell does this. Unfortunately it's painfully inefficient compared to a
>standard serialisation scheme.
>
>I once wrote an interpreter for a domain specific language in Haskell. It
>would parse and typecheck the input language to produce a data structure
>suitable for interpreting. To save the time of parsing and typechecking
>repeatedly I wrote the entire data structure out to a file.
>
>Unfortunately, the resulting file was twice as big as the original input and
>took four times longer to read back in again as it had taken to generate in
>the first place.

I don't think Unify (for that was the name of my lang) serialisation files
would be particularly time-consuming to read in, because structurally they
were rather simple, a bit like Lisp, or Python lists and dictionaries.

The built in data structures were arrays:

    #('this' 'is' 'an' 'array' with 7 'elements')

And NLists (Named Lists, like a dictionary):

   $(_class Point x 3 y 4)

describes the Point (3,4).

Simple types were:

   Integer   45
   Float     3.14159
   String    'hello world'
   Symbol    #Point         (like Smalltalk)
   ByteArray   #[0 255 0 255]

And Pointer, which was like a weak reference in Java, or a symbolic link
in Unix:

   &a.b[3]

means "a relative pointer (starting from where we are) going down into
#a, then #b then 3.

Note that a.b was the same as a[#b].

The keys of NLists were Symbols, which could be any Unify identifier.
If these keys were changed to allow other types of keys as well (particularly
string), and to allow 2 variables to reference the same data structure in 
memory, then Unify would essentially be the same as python (in terms of
its underlying data model -- the rest is all details).

In Python, you can say:

>>> p =[1,2,3]
>>> q=[p]*3
>>> q
[[1, 2, 3], [1, 2, 3], [1, 2, 3]]
>>> q[1][0]='x'
>>> q
[['x', 2, 3], ['x', 2, 3], ['x', 2, 3]]
  
which is the sort of thing some people, including me, found confusing
when learning programming, especially when you can also say:

>>> r = [[1, 2, 3], [1, 2, 3], [1, 2, 3]]
>>> r
[[1, 2, 3], [1, 2, 3], [1, 2, 3]]
>>> r[1][0]='x'
>>> r
[[1, 2, 3], ['x', 2, 3], [1, 2, 3]]  

So (r) looks the same as (q) but behaves differently.

In Unify, if something in fact contains pointers to the same structure,
this is apparent from this sm-format output.

-- 
===== Philip Hunt ===== philh at comuno.freeserve.co.uk =====
* strong public-key email encryption  * automatically decrypt incoming mail
* automatically encrypt outgoing mail, including attachments and headers
* automatically propagate your public key and manage others' public keys
What encryption package does all this? Herbrip, part of the Herbivore
project. <http://www.vision25.demon.co.uk/oss/herbivore/intro.html>