Re: Dylan stuff

mikel evins <[email protected]>
Newsgroups gmane.comp.lang.dylan.gwydion.devel
Message-ID <[email protected]>
On Jan 17, 2013, at 5:33 PM, Bruce Hoult wrote:

> On Fri, Jan 18, 2013 at 12:17 PM, mikel evins <[email protected]> wrote:
>> There are other ways to do it. Common Lisp, for example, doesn't create any accessors unless you explicitly tell it to, and then you have to tell it what names to use. That doesn't guarantee that a program won't unintentionally alias accessors, but it create more opportunities to guard against it, and in practice, I've seen the problem crop up less often in CL programs.
> 
> Surely that's much more because CL has separate namespaces for
> functions and variables?
> 
> When you do...
> 
>  let surname = person.surname;
>  let otherSurname = otherPerson.surname;
> 
> .. there is no problem in CL because the new surname binding is not in
> the same namespace as the accessor function.
> 
> But then you have to uglify some code with (function ...) and (funcall
> ...) when you want to pass functions around and use them.

That's probably true, now that you mention it.

There are still aliasing problem that crop up from time to time--not all aliases are to variable names, and not all function aliasing issues are solved by generic functions. I think the extra step that Common Lisp imposes that forces you to think, if only for a moment, about what your accessors should be named, is a good thing.

That said, I expect you're right.

I also tend to agree that function and funcall in CL are sort of ugly, but that's a matter of taste. Not all Lisp programmers agree

Some people argue that the kind of "uglification" you're talking about is helpful, and I can't say they're wrong. Although I tend to agree with your views, I have nevertheless read a good bit of code that would have been clearer and easier to read if it had been "uglified" a bit.
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.