Re: Snapshot 2015-06

Faré <[email protected]> Thu, 11 Jun 2015 11:48:28 -0400
Newsgroups gmane.lisp.cmucl.devel
Message-ID <CAN7nBXf57NDOwBdxVe0ectrCAtrLVVhWGphZ03-Wx5b+C9A+Ww@mail.gmail.com>
On Thu, Jun 11, 2015 at 2:40 AM, Carl Shapiro <[email protected]> wrote:
> On Wed, Jun 10, 2015 at 11:09 PM, Faré <[email protected]> wrote:
>>
>> Lazy getenv, putenv — and if you want to get all of them, or to pass
>> all of them, use an equal hash-table with strings as key, not an alist
>> with keywords as keys.
>
> Thanks for the clarification.
>
> Is your issue with the search time?  The libc getenv and putenv uses a
> linear search with a linear time compare of strings.  It is unlikely to be
> faster than an a-list search.
>
My issue is that ext:*environment-list* is an abstraction inversion.
Instead of providing a higher-level view on an existing API, it
reinvents a new low-level data structure that doesn't provide any
performance advantage (indeed, only slowdown) yet introduces a new
semantic gap (albeit small) between what was and what is, and only
gets in the way of a further API improvement.

But if you declare it the official way to access the environment in
cmucl, I'll revert to using it.

> I agree that converting strings to keywords is problematic when dealing with
> unconventionally cased environment variable names.  The original strings are
> kept around if you need them.

At this point, it's bikeshedding.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Microphones, liberating singers from having to be loud to be heard, gave back
to each language a music that matches its own prosody.
_______________________________________________
cmucl-imp mailing list
[email protected]
http://lists.zs64.net/mailman/listinfo/cmucl-imp