Cool, thanks.  Although, the clojure reader seems fine for what I need
- i'd like to keep it as simple as possible.  (the whole reason for
doing this is to not have to write a parser for a whole new rule file
format) I just wanted the extra meta data, if it was easy to grab.
Seems like there could be an *attach-metadata* flag or something for
calls to read - since there is clearly code that already exists that
knows how to compute it.

Kevin


On Apr 19, 4:44 pm, Kevin Downey <redc...@gmail.com> wrote:
> if you really want I have a port of LispReader to clojure, it only
> adds metadata to list forms, like LispReader, but altering it should
> not be too hard. I haven't made any attempt to keep the reader up to
> date, but I don't believe LispReader is under going very many changes.
>
> http://github.com/hiredman/clojure/blob/readerII/src/clj/clojure/read...
>
> On Mon, Apr 19, 2010 at 11:43 AM, Kevin Livingston
>
>
>
>
>
> <kevinlivingston.pub...@gmail.com> wrote:
> > SO as a complete hack to get file and line number metadata I
> > implemented this macro, my file of rules is now just loaded with load-
> > file and the rules that are define in it with RULE have the
> > appropriate file and line associated with them.  This is compete abuse
> > of DEF and maybe the compiler (although it's not too dissimilar from
> > very valid approaches in common lisp), but is this creating any
> > ridiculous side effects that I should be aware of?  is using the same
> > symbol to def to over and over and over again bad?  register rule is
> > what takes care of putting the rule that was constructed where I need
> > it to be.
>
> > in common lisp I would use a progn here I used a let with no bindings,
> > is there a better way in clojure?
>
> > (defmacro RULE
> >  "macro for creating an registering a rule"
> >  [& params]
> >  ;; is there a way to do this without the let? this is progn?
> >  `(let []
> >     ;;def is used as a hack to get file name and line number metadata
> >     ;;  arguably instead of using a repeated symbol, rules could be
> >     ;;  def'ed to their own name, except that would create a lot of
> > vars
> >     ;;  which likely are never needed and would waste memory?
> >     (def r# (verify-name (struct-map rule ~...@params)))
> >     ;; gets the metatdata from the var, but changes :name to rule's
> > name
> >     (let [reg-r# (with-meta r# (assoc (meta (var r#)) :name (:name
> > r#)))]
> >       (register-rule reg-r#)
> >       reg-r#)))
>
> > On Apr 17, 10:48 am, Per Vognsen <per.vogn...@gmail.com> wrote:
> >> On Sat, Apr 17, 2010 at 2:29 AM, Kevin Livingston
>
> >> <kevinlivingston.pub...@gmail.com> wrote:
> >> > I have an application that will read in a large number of structures
> >> > from a file.  those structures will be used throughout the application
> >> > to produce additional data etc.  since they are "user" configurable,
> >> > it would be nice to know where they come from should one of them start
> >> > misbehaving.  the type of metadata the compiler associates with
> >> > function definitions etc. would be very valuable.  if I'm reading my
> >> > structures in with (read) is there anyway to get it to attach filename
> >> > and line-number etc. metadata?
>
> >> The reader doesn't do that but you can easily do it yourself if you
> >> only want to annotate top-level values.
>
> >> Thinking about this made me realize that it would be nice if the
> >> reader reentered itself (as it does in LispReader's
> >> readDelimitedList() and a few other contexts) through a var so it
> >> could be rebound by a programmer. Then you could inject your own line
> >> number annotation into the reader which would apply not only to
> >> top-level values (e.g. a vector literal) but also its subvalues (e.g.
> >> the elements of the vector literal).
>
> >> -Per
>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clojure@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with 
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+unsubscr...@googlegroups.com
> >> For more options, visit this group 
> >> athttp://groups.google.com/group/clojure?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with 
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/clojure?hl=en
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group 
> athttp://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en

Reply via email to