[Openmcl-devel] A question about ticket #400

Ron Garret ron at awun.net
Mon Jun 22 11:46:56 PDT 2009


IMHO, it's a mistake to put code in files at all, especially Lisp  
code.  Lisp code isn't text, it's a data structure.  It belongs in a  
database, not a file.  The idea that code consists of lines of text is  
a leftover from the days when code resided on punched cards.

rg


On Jun 22, 2009, at 10:50 AM, Dan Weinreb wrote:

> Any approach that involves storing data in a separate file
> runs into problems when someone tries to move the file,
> rename the file, mail the file, back up the file, compress
> the file, put the file into an archive file, and so on.
> -- Dan
>
> Glen Foy wrote:
>>
>> On Jun 20, 2009, at 12:44 PM, Gail Zacharias wrote:
>>
>>> Yeah, here's the thing...  The API can easily provide any number of
>>> functions such as save/load-buffer-as-html or save/load-buffer-as-
>>> rtf or save/load-buffer-in-home-baked-format-with-font-info-encoded-
>>> in-lisp-comments or whatever, stuff like that would be trivial to
>>> write.  The problem is that it's not clear to me what Hemlock should
>>> actually do to save the attributes, given the reality of living in a
>>> unix file system.  Any thoughts?
>>>
>>
>> If we are just talking about Hemlock as a source code editor, it may
>> not be necessary or even desirable to distribute styled files.
>> Everyone has their own idea of what source code should look like  
>> anyway.
>>
>>  From that point of view, the styling information could be stored in
>> an associated invisible file and distributed or not distributed as  
>> the
>> author saw fit.  When hacking, Hemlock would look for the associated
>> file, using it if it was there.  This would be a simple solution.
>>
>>
>> People may, however, want to use Hemlock for other purposes.  In  
>> which
>> case the two file approach is not so good.
>>
>>
>> This issue clearly needs some brainstorming.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090622/2ced4400/attachment.htm>


More information about the Openmcl-devel mailing list