Re: when to use strings, when to use symbols
() Andy Wingo () Sat, 08 Jan 2011 18:25:32 -0800 * Use symbols when you want to match against a symbol literal in your source code. * Use strings otherwise. Symbols are preferable whenever ‘eq?’ is important (for whatever reason, depending on program design). Many times that involves matching against a symbol literal, but that's a specific case. For example, if the accepted alist is intended for key duplicates pruning, using a symbol in the key means you can use ‘assq’ (i.e., ‘eq?’), which can be (and usually is) more performant than ‘assoc’.
Re: when to use strings, when to use symbols
On 9 Jan 2011, at 03:25, Andy Wingo wrote:
Let's say you have an association list. It could be (("foo" .
"bar")) or
((foo . "bar")) or ((foo bar)), or even (("foo" . bar)). If you're
parsing this data from over the network, in textual form, which do you
use?
The answer is this:
* Use symbols when you want to match against a symbol literal in your
source code.
* Use strings otherwise.
I have found very useful the associative container with keys
implemented as a balanced tree and called std::map in C++ and Map in
Haskell. The keys then varies according to context. For example,
sparse multivariate polynomials can be implemented as a map from
monomials to coefficients. Then sparse multivariate monomials can be
implemented as a map from variables to exponents (integers); for
variables, I choose strings.
ps. I very, very rarely hold Python up as an example of language
design,
especially regarding strings, but I think that their approach to
string
mutabililty and identity is preferable to the symbol vs string
distinction that Scheme has.
Symbols and strings are semantically different with respect to the
lambda theory. Perhaps in Scheme, symbols are used in other contexts
because 'eq?' is faster, which was important on the slower computers
of the past.
Re: Problems building GNU Greg testing framework
Hi! ro...@lavabit.com writes: > I'm trying to build GNU Greg 1.4 in order to build Guile DBI but when I > run ./configure something goes wrong. > > $ ./configure --prefix $HOME/opt/ > loading cache ./config.cache > checking host system type... Invalid configuration > `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized This means that Greg’s ‘config.guess’ (which originates from Autoconf) is very, very old, and doesn’t know this architecture, leading to: > ltconfig: you must specify a host type if you use `--no-verify' > Try `ltconfig --help' for more information. > configure: error: libtool configure failed AFAIK Greg has been mostly unmaintained for several years. Still, you could try regenerating the configure machinery with a current Autoconf and see what happens. Thanks, Ludo’.
