help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Writing a function/macro in Elisp that generates a function at runti


From: Toby Cubitt
Subject: Re: Writing a function/macro in Elisp that generates a function at runtime
Date: Tue, 28 Oct 2008 18:10:10 +0100
User-agent: Thunderbird 2.0.0.17 (X11/20080929)

Hi Ted,

Thanks for taking the time to reply.

Ted Zlatanov wrote:
> On Tue, 28 Oct 2008 13:42:57 +0100 Toby Cubitt <tsc25@cantab.net> wrote: 
> 
> TC> I have a higher-level data structure built on top of a lower-level one.
> TC> Internally, the higher-level structure stores data "cells" in the
> TC> lower-level structure. The lower-level structure of course knows nothing
> TC> about this. It just stores any kind of data, without knowing anything
> TC> about its structure. And users of the higher-level structure also know
> TC> nothing about the data cells, which are part of the internal
> TC> implementation. As far as users are concerned, they can just store data
> TC> of whatever kind they like in the higher-level structure.
[snip]

> I don't understand why you're trying to cross between the storage and
> the logic (essentially, that's what your "low level" and "high level"
> layers are).  The logic layer should know how to convert its data to and
> from a neutral data format (in Lisp, that's usually a list).  The
> storage layer should just store and retrieve the neutral data format.

It's difficult to motivate it whilst trying to avoid explaining the
entire code :)  I don't really want to get into a discussion here about
general design issues, since it's not appropriate to this list. The
trouble is, it's difficult to explain why I can't just use the simple
solution proposed by Barry Margolin without explaining a bit of the
background.

I'm not too sure what you mean by "logic layer", but I'm not doing
anything as complicated as that sounds. The data structures are just
that: data structures (they're a kind of tree, with some extra gubbins
on top), along with a bunch of functions for using them. (In OOP these
"higher-level" and "lower-level" data structures would be two different
classes, the functions would be class methods, and the "high-level"
class would contain an instance of the "low-level" one. The 'has-a'
relationship, i.e. one containing the other, is the reason I was calling
them "higher-level" and "lower-level", nothing more complicated than that.)


> Your approach makes sense, IMO, in an OOP environment where every object
> knows how to serialize itself.

Off-topic, one thing I love about Lisp is that it's so easy to take the
good parts of OOP and use them directly, without any of the OOP
complexity and mess. The good bits are already there as soon as
functions are first-class objects!.....Any replies to these comments
should be directed off-list, though :)


> I got the following from
> http://dorophone.blogspot.com/ and it may help you to sort-of-do
> serializable objects if that's your goal...  You just print the value of
> each object you create, and later you can eval them back in.

Interesting, but this is certainly overkill for what I'm doing.

Toby




reply via email to

[Prev in Thread] Current Thread [Next in Thread]