Actually, it occurred to me that re-assembling the symbols in the
recipe/module might involve macrology, in order to put in the
following format:
MEDICATION QUANTITY LINE NUMBER FORM
INSTRUCTIONS
(that's like OMZ20 30CP INSTOMZ that I exemplified in another message,
expanding to:
Omeprazol 20mg ----------------------- 30 pills
Take 1 P.O. etc.)
So...bad! Or worse, parsers etc Which would take me a whole lot of
time (Dragon book? R U kidding me?! ;-))
Cheers,
Henry Lenzi
On Wed, Jul 30, 2014 at 10:57 PM, Henry Lenzi <henry.le...@gmail.com> wrote:
> Actually, this is interesting.
>
> This might lead to having hundreds of definition files, however (say,
> one for each medication defintion).
>
> I would have to look into how I can save a module to a file (Alexander
> Knauth explained that (write '(define hctz25 "Hydrochlorothiazide
> 25mg") out) would write the correct definition to a file.
>
> So, a recipe might be just a module. The symbols would be correctly
> imported (and "interned", I suppose you guys say...?) in the run-time.
>
> Thanks, Vincent.
>
> Cheers,
> Henry
>
> On Mon, Jul 28, 2014 at 6:03 PM, Vincent St-Amour <stamo...@ccs.neu.edu>
> wrote:
>> Henry,
>>
>> It looks like modules may be what you're looking for.
>>
>> You could have a file that defines a substance and exports it
>>
>> ;; a.rkt
>> #lang racket
>> (provide hctz25)
>> (define hctz25 "Hydrochlorothiazide 25mg")
>>
>> and then a recipe file that imports the previous file
>>
>> #lang racket
>> (require "a.rkt")
>> hctz25
>>
>> The module system is the preferred way to share definitions across
>> multiple files in Racket.
>>
>> Would that solve your problem?
>>
>> Vincent
>>
>>
>> At Mon, 28 Jul 2014 17:21:40 -0300,
>> Henry Lenzi wrote:
>>>
>>> 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
____________________
Racket Users list:
http://lists.racket-lang.org/users
