I don’t think you even need to serialize it for that: (define my-hash (make-hash)) (define out (open-output-file “dump.dat”)) (write my-hash out) (close-output-port out)
… later (define in (open-input-file “dump.dat”)) (define my-hash (read in)) (close-input-port in) On Jul 28, 2014, at 11:59 PM, Roman Klochkov <kalimeh...@mail.ru> wrote: > 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.le...@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 <n...@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 > ____________________ > Racket Users list: > http://lists.racket-lang.org/users
____________________ Racket Users list: http://lists.racket-lang.org/users
