That is a surprising (until you think about it) difference in behavior.
(ctx "bar") returns a setf-able place, or nil. but referencing an unbound symbol always returns a setf-able place.
[bof?] ++ nil val in hashmap fails -> feature
6 posts
• Page 1 of 1
[bof?] ++ nil val in hashmap fails -> feature
by hartrock » Tue Jun 30, 2015 11:37 am
Last edited by hartrock on Sat Jul 25, 2015 9:00 am, edited 1 time in total.
- hartrock
- Posts: 136
- Joined: Wed Aug 07, 2013 9:37 pm
Re: [bof?] ++ nil val in hashmap fails
by xytroxon » Tue Jun 30, 2015 3:52 pm
"Many computers can print only capital letters, so we shall not use lowercase letters."
-- Let's Talk Lisp (c) 1976
-- Let's Talk Lisp (c) 1976
- xytroxon
- Posts: 296
- Joined: Tue Nov 06, 2007 3:59 pm
Re: [bof?] ++ nil val in hashmap fails
by TedWalther » Wed Jul 01, 2015 6:08 am
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
- TedWalther
- Posts: 605
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
Re: [bof?] ++ nil val in hashmap fails
by hartrock » Thu Jul 02, 2015 1:14 am
Thanks for clearifying the difference between symbols and Tree or (ctxt "someKey") hashmap values.
My usecase is a state machine modeled by a hash map with string state IDs as keys, where I want to count state changes. So I have two Tree hash maps: one for the states, another for the counters; both with same string keys.
Best solution I think is to init the corresponding counter hash map val with 0, just with adding a new state to state machine hashmap (which will be done by a func); so above check for nil can be omitted.
Using symbol keys for states like sm:someState would be possible, too; but then there could be a conflict with funcs like sm:add-state, located in same context as state hashmap.
My usecase is a state machine modeled by a hash map with string state IDs as keys, where I want to count state changes. So I have two Tree hash maps: one for the states, another for the counters; both with same string keys.
Best solution I think is to init the corresponding counter hash map val with 0, just with adding a new state to state machine hashmap (which will be done by a func); so above check for nil can be omitted.
Using symbol keys for states like sm:someState would be possible, too; but then there could be a conflict with funcs like sm:add-state, located in same context as state hashmap.
Last edited by hartrock on Thu Jul 02, 2015 1:35 am, edited 1 time in total.
- hartrock
- Posts: 136
- Joined: Wed Aug 07, 2013 9:37 pm
Re: [bof?] ++ nil val in hashmap fails
by TedWalther » Thu Jul 02, 2015 1:31 am
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
- TedWalther
- Posts: 605
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
Re: [bof?] ++ nil val in hashmap fails
by xytroxon » Thu Jul 02, 2015 6:42 am
"Many computers can print only capital letters, so we shall not use lowercase letters."
-- Let's Talk Lisp (c) 1976
-- Let's Talk Lisp (c) 1976
- xytroxon
- Posts: 296
- Joined: Tue Nov 06, 2007 3:59 pm
6 posts
• Page 1 of 1
Return to newLISP in the real world
Who is online
Users browsing this forum: No registered users and 1 guest