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