[racket] Use of map and eval to evaluate symbol in namespace

 You may also export all hash to file and later read it.

http://docs.racket-lang.org/reference/serialization.html

(require racket/serialize)

(define my-hash (make-hash))

(define out (open-output-file "dump.dat"))
(write (serialize my-hash) out)
(close-output-port out)

... later
(define in (open-input-file "dump.dat"))
(define my-hash (deserialize (read in)))
(close-input-port in)

Mon, 28 Jul 2014 17:21:40 -0300 от Henry Lenzi <henry.lenzi at gmail.com>:
>Hi Neil --
>
>So how do you export hash keys as symbols to a file that can be read
>in again, not as string?
>
>Now, I haven't gotten around to reading the whole of Racket Scheme's
>documentation... Things are looking kind of hard.
>
>What I'm attempting to do is then read back the symbols defined, such
>as the one below:
>
>(define hctz25 "Hydrochlorothiazide 25mg")
>
>> (close-input-port in)
>> (define in (open-input-file "Recipe.txt"))
>> (string->symbol (read-line in))
>'|'hctz25|
>
>But what I really want is the "hctz25" symbol that evaluates to a
>string. If I don't use string->symbol, I get the string "hctz25". And
>why the bars ("|")? I've read
>
>  http://docs.racket-lang.org/reference/reader.html#%28part._parse-hashtable%29
>
>but it didn't help me much.
>
>Of course, the ultimate purpose would be to re-evaluate the imported
>symbol and reconstruct a medical recipe. The purpose of these
>baby-steps exercises is porting a medical recipe program I've written
>originally in Forth that allowed me to service 5.000 patients creating
>a little database of shorthand recipes that then expand into real
>medical recipes. I got hundreds of patients on renewable recipes for,
>say, hypertension. Hand writing is no fun. Typing them in Word is no
>fun. The hospital has is its own software, but it's is a load of
>baloney, extremely buggy, if you ask me, so I'm rolling my own again,
>except I want to print directly on the model paper our service uses,
>so I want graphics like Racket Scheme has (very good capabilities, as
>far as my needs are concerned).
>
>With Forth, it's very easy to design DSLs, because there's no syntax
>and you get a lot of advanced features for free. For instance, there's
>no need to write a parser for my little language. However, since Forth
>implementations fall short of dealing with images, graphics (unless
>you take the royal road to pain and learn to program for the Win32 API
>and how it works for a particular Forth vendor), I'm looking at Racket
>Scheme.
>
>TIA,
>
>Henry Lenzi
>
>
>
>
>
>
>
>
>On Mon, Jul 28, 2014 at 4:46 PM, Neil Van Dyke < neil at neilvandyke.org > wrote:
>> I don't know the current state of the "eval" docs in the manual, but I think
>> they should have a big warning at the very front, intended to scare away
>> newbies.
>>
>> Remember that Racket is often used in conjunction with many different
>> Scheme-based and other Lisp-based textbooks and courses. It seems that many
>> CS instructors and textbook authors like to talk about ``EVAL'' (as an
>> abstract operation) when talking about some models of evaluation, and "eval"
>> (as an accessible language binding) to say, gosh, aren't dynamic languages
>> interesting and powerful. So, we can't blame every fourth newbie for trying
>> to use "eval" unnecessarily, in ways that make for bad software engineering.
>>
>> Given this reality of confusing instruction, I'm thinking that, as a
>> reactive measure, "#lang paddle" will disable "eval" by default. Attempting
>> to use "eval" will give you an error message, unless you have an assertion
>> form like
>> "(i-have-read-the-foo-document-and-understand-that-eval-is-usually-the-wrong-thing-but-honest-i-know-what-i-am-doing)".
>>
>> Cheers,
>> Neil V.
>>
>> Vincent St-Amour wrote at 07/28/2014 02:21 PM:
>>
>>> Maybe this should be linked to from the `eval' docs?
>>>
>>>
>>>  http://blog.racket-lang.org/2011/10/on-eval-in-dynamic-languages-generally.html
>>>
>>> Vincent
>>>
>>>
>>> At Sun, 27 Jul 2014 16:16:52 -0400,
>>> Neil Van Dyke wrote:
>>>>
>>>> Maybe there should be a periodic public service announcement about not
>>>> using "eval".  This time I will communicate in FAQ format:
>>>>
>>>> Q: How do I use eval?
>>>> A: Don't use eval.
>>>>
>>>> Q: But don't so many academic books feature eval prominently, so doesn't
>>>> that mean I should use try to eval?
>>>> A: Those books use eval for pedagogic reasons, or because the author is
>>>> enamored of some theoretical appeal of eval, or because the author wants
>>>> to watch the world burn.  Don't use eval.
>>>>
>>>> Q: But, but, but, I am just starting to learn, and eval seems to do what
>>>> I need.
>>>> A: Eval is almost certainly not what you want.  Learn how to use the
>>>> other basics effectively.  Don't use eval.
>>>>
>>>> Q: I now am very comfortable with the language, I am aware that I should
>>>> avoid eval in almost all cases, and I can tell you why eval is actually
>>>> the right thing in this highly unusual case.
>>>> A: Cool, that's why eval is there.
>>>>
>>>> Neil V.
>>>>
>>
>> ____________________
>>  Racket Users list:
>>  http://lists.racket-lang.org/users
>____________________
>  Racket Users list:
>   http://lists.racket-lang.org/users


-- 
Roman Klochkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140729/6eba903e/attachment.html>