axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Literated VMLISP.LISP.PAMPHLET


From: Kai Kaminski
Subject: Re: [Axiom-developer] Literated VMLISP.LISP.PAMPHLET
Date: Fri, 22 Sep 2006 18:48:46 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (darwin)

Ralf Hemmecke <address@hidden> writes:

>>> Hmmm, I am not sure I can support that approach. For two reasons.
>>>
>>> 1) Most probably the aliases come in the documentation without links
>>> to the code they refer to. (Though that can be done.)
>> I'm not quite sure what exactly you're getting at.
>
> Have you, for example ever used
>
> @ %def foo
>
> at the end of a code chunk? noweave can generated hyperlinks inside
> the code pieces from that...
No, I haven't. I didn't really know about that. I'll add it to noweb
(even though it's a shame that you have to do that by hand).

>>> 2) You separate code that belongs together. Don't you think?
>> I suppose you mean that an alias definition should be next to the
>> definition of the function that it's an alias for? Like
>>
>> <<foo>>=
>>
>> (defun foo (...)
>>   ...)
>>
>> (define-function alias-for-foo #'foo)
>> @
>>
>> That's what I thought at first, but then it occured to me that
>>
>> 1) Aliases in general aren't terribly useful. The only exception I can
>>    think of is the following. Suppose you have an operation acting on
>>    objects of type FOO, say COMPARE-FOOS. Now it happens that the
>>    definition of that function is
>>
>>      (defun compare-foos (&rest foos)
>>        (apply #'equal foos))
>>
>>    In this case it is acceptable to create COMPARE-FOOS, because it
>>    captures a different concept. This is also useful if you later
>>    change the implementation of objects of type FOO, and you can't
>>    just compare them with EQUAL. In that case you simply change the
>>    implementation of COMPARE-FOOS. If you'd use EQUAL directly, you'd
>>    have to check each and every EQUAL in your source to figure out
>>    wether it has to be adapted to the new implementation of FOOs.
>>
>>    Other than that I don't see any justification for aliases.
>
> I cannot say much about that. I am not a LISP programmer. :-(
Maybe I should have tried to explain this better, since I don't think
that this is specific to Lisp. In general, when does it make sense to
have several different names for a single function? Not very often,
I'd say.

>>> Why would it make sense to list all the abbreviations on one section
>>> (even without documenation)?
>> Because they're all obsolete. That section is a list of things to
>> remove.
>
> Hmmm, in that case, the section would not be forever. So I am with you.
Yes, it's supposed to disappear.

>>>> Thanks for taking the time to discuss - admittedly boring - details.
>>> I don't think that it is "boring". I am sure that most of us have no
>>> real experience what the best LP style in Axiom would be. Otherwise I
>>> would have seen a "Conventions" page that explains how to write good
>>> literate programs. It's not totally clear, at least not for me.
>> Not to me, either. When I read your first response to my VMLISP.LISP
>> conversion I actually thought about that. I was going to suggest that
>> you put up the example you gave (the Groebner basis fragment).
>
> All I can put onto the net is already there. My experience of
> programming in LP style is at the ALLPROSE website. I am sure that I
> am not perfect, but the whole thing is a bit bigger than just
> dhmatrix.
I looked at your ALLPROSE when Martin mentioned it to me. It's quite
impressive as far as I can see, but I didn't spend enough time with it
to say anything about it.

> And I am currently doing something here...
>
> svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/trunk combinat
> cd combinat/combinat
> make colored dvi
I'll take a look.

Thanks,
Kai




reply via email to

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