Re: `let` to automatically add metadata / fn names?
vary-meta slipped my mind! I've updated the gist to include it. The reason I check for IObj and IMeta is that I want symbols and other custom deftypes to recieve the metadata as well. I thought about namespacing the let-names, but for my current purposes I don't need that extra data (although I can imagine when it would be useful, and a complete implementation should store the namespace, the line number, and maybe further info). I am using this in my project Piplin, a DSL for programming FPGAs in Clojure. I'll be talking about Piplin and some of the embedding tricks I use at Clojure/West. This let' macro gives me a higher-fidelity way to translate Clojure source to Verilog source purely at runtime, which is a different approach from other Clojure cross-compilers. On Sunday, February 10, 2013 7:40:51 PM UTC-5, vemv wrote: > > Glad to hear that Phil! You're entirely right - I didn't realise that > distributing jar to Java consumers doesn't imply AOT-compiling the > libraries at all. > > David, on your implementation - I may be missing something, but why not > just vary-meta each collection found in the bindings? > > Also, it might interest you performing the tagging tree-recursively (e.g. > in (let x [[][][]]) the four colls would get tagged), and with namespaced > names. > > More importantly, how are you using this? One thing I haven't thought > about yet is how to map the "tags" to stack traces. > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
Glad to hear that Phil! You're entirely right - I didn't realise that distributing jar to Java consumers doesn't imply AOT-compiling the libraries at all. David, on your implementation - I may be missing something, but why not just vary-meta each collection found in the bindings? Also, it might interest you performing the tagging tree-recursively (e.g. in (let x [[][][]]) the four colls would get tagged), and with namespaced names. More importantly, how are you using this? One thing I haven't thought about yet is how to map the "tags" to stack traces. -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
I've written an implementation of this
here: https://gist.github.com/dgrnbrg/4751473
It does incur a 2 instance check penalty (the branches should be 100%
predictable, and never hurt in practice). I'm not sure if I could use
protocols to further reduce the cost of the check.
I've already put this into the util.clj in my project that needs this most,
to good effect.
David
On Friday, February 8, 2013 12:18:54 PM UTC-5, vemv wrote:
>
> Given that: a) fns can have names for debugging purposes, and b) data
> structures can have metadata, wouldn't it be a good idea to let let auto
> attach (where possible) the names of the bindings to their corresponding
> values?
>
> For example, the improved let I'm thinking of would translate this input:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn [] (throw (Exception.)))
> bar {:hello (/ 0 0)}]))
>
> to:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn foo [] (throw (Exception.)))
> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>
> This could be used to increase the precision of the stack traces, or in
> IDEs/editors for locating the exact source of an exception.
>
> Do you see such a mechanism being incorporated to clojure.core/let -
> should I open a ticket?
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
On Sat, Feb 9, 2013 at 4:20 PM, vemv wrote:
> Then library consumers can specify either [com.example/awesomelib "1.4.0"],
> [com.example "1.4.0-DEBUG"], or [com.example "1.4.0-NO-DEBUG"] in their
> :dependencies vector, in the corresponding project.clj.
> If no version directive is specified, "DEBUG" would be chosen unless
> specified otherwise in profiles.clj: {:user {:debug-dependencies false}}
>
> Does it sound good enough?
I like this idea a lot, but I would like to point out that the flags
you're talking about apply at compile time, which is usually not the
same as jar distribution time. Consider it in terms of these:
* Compilation during development
* Compilation for library distribution (very rare)
* Compilation for application distribution
Granted there are a few libraries which require AOT compilation before
distribution, but these are few and far between. I'm curious now as to
what the percentage is here; maybe I can scan through the Clojars
corpus. I would expect it to be well under 5%; perhaps even under 1%.
In addition, libraries that do AOT already have to deal with
incompatibilities between major Clojure versions, so they probably
already distribute a set of versions compiled slightly differently.
Typically in Maven repositories these are handled by the :classifier
rather than the version, but the end result is the same; the group id,
artifact id, version, classifier, and packaging/extension are all part
of what uniquely identifies an artifact. The problem is that since
different classifiers distinguish different artifacts, adding the
"nodebug" classifier will not cause the default version to be
excluded; you'll need an explicit :exclusion for it. This can get
hairy if things are being pulled in transitively.
Anyway, the tl;dr is that this is a setting which won't be needed for
distribution when considering the vast majority of jars. For those few
that do need it, it would probably be simpler just to force a
recompile when the entire application is compiled rather than dealing
with classifiers. In fact, defaulting to leaving them off and making
it the responsibility of Leiningen (or whatever is launching the
development environment) to turn them on during development time might
be the simplest thing.
-Phil
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
Thanks for the advice Stu! I might give it a shot at Confluence at some
point. Just for the record, I like to defend my hypotethical approach:
Non-Clojure consumers most likely win nothing from extended metadata
facilities etc. So on second thoughts, the best default for "mylib-*1.0.0*.jar"
is to turn them off.
But on the Lein side, even if you specify [mylib *"1.0.0"*], *"*mylib-*
1.0.0-DEBUG*.jar*"* gets fetched instead unless one specifies otherwise,
which'd be the exception rather than the rule.
That way we'd get the best of both worlds - zero noise for Java consumers
or constrained Clojure envs, and full / a la carte facilities for the
majority of Clojure library producers and consumers.
On Sun, Feb 10, 2013 at 1:59 AM, Stuart Halloway
wrote:
> It is likely that, once this Pandora's box is opened, there will be more
> profiles that just debug yes/no.
>
> It is almost certain that whatever we do must be maven friendly. (Maven
> is a de facto standard for 1000x more people than leiningen, and some of
> them want to use libs written in Clojure.)
>
> If you are excited about doing this design work, please start a page in
> Confluence, and capture your goals, options, tradeoffs, and recommendations.
>
> Stu
>
>
> On Sat, Feb 9, 2013 at 7:20 PM, vemv wrote:
>
>> I had something like this in mind:
>>
>>- There's a set of clojure.core vars that mean something
>>(potentially) expensive yet convenient, and default to true
>>- Neither library producers or consumers have ever to touch those
>>(unless they want fine-grained control for some specific var/context)
>>- When performing a release to clojars or central, Lein creates two
>>versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and
>>false, respectively
>>- Then library consumers can specify either [com.example/awesomelib *
>>"1.4.0"*], [com.example *"1.4.0-DEBUG"*], or [com.example *
>>"1.4.0-NO-DEBUG"*] in their :dependencies vector, in the
>>corresponding project.clj.
>>- If no version directive is specified, "DEBUG" would be chosen
>>unless specified otherwise in profiles.clj: {:user {:debug-dependencies
>>false}}
>>
>> Does it sound good enough?
>>
>>
>> On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>>>
>>> Given that: a) fns can have names for debugging purposes, and b) data
>>> structures can have metadata, wouldn't it be a good idea to let letauto
>>> attach (where possible) the names of the bindings to their
>>> corresponding values?
>>>
>>> For example, the improved let I'm thinking of would translate this
>>> input:
>>>
>>> (ns my.namespace)
>>>
>>> (defn do-it
>>> (let [foo (fn [] (throw (Exception.)))
>>> bar {:hello (/ 0 0)}]))
>>>
>>> to:
>>>
>>> (ns my.namespace)
>>>
>>> (defn do-it
>>> (let [foo (fn foo [] (throw (Exception.)))
>>> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>>>
>>> This could be used to increase the precision of the stack traces, or in
>>> IDEs/editors for locating the exact source of an exception.
>>>
>>> Do you see such a mechanism being incorporated to clojure.core/let -
>>> should I open a ticket?
>>>
>> --
>> --
>> 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
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
> --
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
--
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.
Re: `let` to automatically add metadata / fn names?
It is likely that, once this Pandora's box is opened, there will be more
profiles that just debug yes/no.
It is almost certain that whatever we do must be maven friendly. (Maven is
a de facto standard for 1000x more people than leiningen, and some of them
want to use libs written in Clojure.)
If you are excited about doing this design work, please start a page in
Confluence, and capture your goals, options, tradeoffs, and recommendations.
Stu
On Sat, Feb 9, 2013 at 7:20 PM, vemv wrote:
> I had something like this in mind:
>
>- There's a set of clojure.core vars that mean something (potentially)
>expensive yet convenient, and default to true
>- Neither library producers or consumers have ever to touch those
>(unless they want fine-grained control for some specific var/context)
>- When performing a release to clojars or central, Lein creates two
>versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and
>false, respectively
>- Then library consumers can specify either [com.example/awesomelib *
>"1.4.0"*], [com.example *"1.4.0-DEBUG"*], or [com.example *
>"1.4.0-NO-DEBUG"*] in their :dependencies vector, in the corresponding
>project.clj.
>- If no version directive is specified, "DEBUG" would be chosen unless
>specified otherwise in profiles.clj: {:user {:debug-dependencies false}}
>
> Does it sound good enough?
>
>
> On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>>
>> Given that: a) fns can have names for debugging purposes, and b) data
>> structures can have metadata, wouldn't it be a good idea to let let auto
>> attach (where possible) the names of the bindings to their corresponding
>> values?
>>
>> For example, the improved let I'm thinking of would translate this input:
>>
>> (ns my.namespace)
>>
>> (defn do-it
>> (let [foo (fn [] (throw (Exception.)))
>> bar {:hello (/ 0 0)}]))
>>
>> to:
>>
>> (ns my.namespace)
>>
>> (defn do-it
>> (let [foo (fn foo [] (throw (Exception.)))
>> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>>
>> This could be used to increase the precision of the stack traces, or in
>> IDEs/editors for locating the exact source of an exception.
>>
>> Do you see such a mechanism being incorporated to clojure.core/let -
>> should I open a ticket?
>>
> --
> --
> 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
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
I had something like this in mind:
- There's a set of clojure.core vars that mean something (potentially)
expensive yet convenient, and default to true
- Neither library producers or consumers have ever to touch those
(unless they want fine-grained control for some specific var/context)
- When performing a release to clojars or central, Lein creates two
versions ("DEBUG", "NO-DEBUG"), in which the vars are set to true and
false, respectively
- Then library consumers can specify either [com.example/awesomelib *
"1.4.0"*], [com.example *"1.4.0-DEBUG"*], or [com.example *
"1.4.0-NO-DEBUG"*] in their :dependencies vector, in the corresponding
project.clj.
- If no version directive is specified, "DEBUG" would be chosen unless
specified otherwise in profiles.clj: {:user {:debug-dependencies false}}
Does it sound good enough?
On Friday, February 8, 2013 6:18:54 PM UTC+1, vemv wrote:
>
> Given that: a) fns can have names for debugging purposes, and b) data
> structures can have metadata, wouldn't it be a good idea to let let auto
> attach (where possible) the names of the bindings to their corresponding
> values?
>
> For example, the improved let I'm thinking of would translate this input:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn [] (throw (Exception.)))
> bar {:hello (/ 0 0)}]))
>
> to:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn foo [] (throw (Exception.)))
> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>
> This could be used to increase the precision of the stack traces, or in
> IDEs/editors for locating the exact source of an exception.
>
> Do you see such a mechanism being incorporated to clojure.core/let -
> should I open a ticket?
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
Are you thinking that the client developer (the person using the library) would maintain the proper magic ear-muffs in lein profiles? On Saturday, February 9, 2013 3:17:51 PM UTC-8, vemv wrote: > > Going the build route, probably use maven to produce debug and production >> artifacts of differing versions: blah-1.0.0-DEBUG.jar and blah-1.0.0.jar. >> > > My thoughts too. And there's no need for convention madness - e.g. > Leiningen could transparently create those versions to the user: the > "NO-DEBUG" versions would simply set certain vars to false. For example, > for the idea I'm proposing there would be *tagging-let*, which defaulted > to true. > > Would this adress the Android story as well? > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
> > Going the build route, probably use maven to produce debug and production > artifacts of differing versions: blah-1.0.0-DEBUG.jar and blah-1.0.0.jar. > My thoughts too. And there's no need for convention madness - e.g. Leiningen could transparently create those versions to the user: the "NO-DEBUG" versions would simply set certain vars to false. For example, for the idea I'm proposing there would be *tagging-let*, which defaulted to true. Would this adress the Android story as well? -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
Going the build route, probably use maven to produce debug and production artifacts of differing versions: blah-1.0.0-DEBUG.jar and blah-1.0.0.jar. Rather than go that route and the ensuing naming convention madness, I wonder how much we could rely on the JIT to push the decision of debug vs production to runtime? On Saturday, February 9, 2013 6:31:10 AM UTC-8, stuart@gmail.com wrote: > > +1 on this line of thought. We are definitely interested in decomplecting > dev mode utility from production lean-and-meanness. > > One question along this path is "What options exist in Java/maven land for > doing multiple releases of the same artifact with e.g. different > performance and debugging characteristics, and how could these be > incorporated into the Clojure build in a transparent, easy-to-assess way?" > > Answering the preceding question (or reframing it into a better question) > is not blocked waiting on anybody. Have at it! > > Stu > > > On Fri, Feb 8, 2013 at 9:36 PM, Brian Marick > > wrote: > >> >> On Feb 8, 2013, at 7:56 PM, Daniel Glauser > >> wrote: >> >> > >> > This sounds like a great idea. I was working with some tests today and >> it would have been really useful to have some way to query the current >> function/execution context. Seems like passing that through all lets would >> go a long way, provided I'm reading this right. >> >> It would be very interesting to have a "maximally informative mode" and a >> "generate really tense code" mode. There is tradition behind such an idea. >> >> It would be especially interesting if the maximally informative mode had >> hooks tools could exploit. For example, Midje provides a hack where you can >> declare records in a way that the contained functions can be mocked: >> `defrecord-openly`. I expect almost no one uses it, even though it is no >> different than `defrecord` when in "production mode": it's too weird >> looking. But people would use it if ordinary defrecord methods weren't >> inlined during development. >> >> There's no *semantic* reason why parts of Clojure should *always* be >> closed to introspection-type actions. It's purely a matter of time >> constraints on the core team, which I am certainly not in a position to >> judge. How much core time should be spent on saving anonymous programmers >> time vs. saving cycles for anonymous apps running on the Amazon cloud? It's >> a tough tradeoff. >> >> >> Looking for 1/2-time employment as a Clojure programmer >> Latest book: /Functional Programming for the Object-Oriented Programmer/ >> https://leanpub.com/fp-oo >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
+1 on this line of thought. We are definitely interested in decomplecting dev mode utility from production lean-and-meanness. One question along this path is "What options exist in Java/maven land for doing multiple releases of the same artifact with e.g. different performance and debugging characteristics, and how could these be incorporated into the Clojure build in a transparent, easy-to-assess way?" Answering the preceding question (or reframing it into a better question) is not blocked waiting on anybody. Have at it! Stu On Fri, Feb 8, 2013 at 9:36 PM, Brian Marick wrote: > > On Feb 8, 2013, at 7:56 PM, Daniel Glauser wrote: > > > > > This sounds like a great idea. I was working with some tests today and > it would have been really useful to have some way to query the current > function/execution context. Seems like passing that through all lets would > go a long way, provided I'm reading this right. > > It would be very interesting to have a "maximally informative mode" and a > "generate really tense code" mode. There is tradition behind such an idea. > > It would be especially interesting if the maximally informative mode had > hooks tools could exploit. For example, Midje provides a hack where you can > declare records in a way that the contained functions can be mocked: > `defrecord-openly`. I expect almost no one uses it, even though it is no > different than `defrecord` when in "production mode": it's too weird > looking. But people would use it if ordinary defrecord methods weren't > inlined during development. > > There's no *semantic* reason why parts of Clojure should *always* be > closed to introspection-type actions. It's purely a matter of time > constraints on the core team, which I am certainly not in a position to > judge. How much core time should be spent on saving anonymous programmers > time vs. saving cycles for anonymous apps running on the Amazon cloud? It's > a tough tradeoff. > > > Looking for 1/2-time employment as a Clojure programmer > Latest book: /Functional Programming for the Object-Oriented Programmer/ > https://leanpub.com/fp-oo > > -- > -- > 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 > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
On Feb 8, 2013, at 7:56 PM, Daniel Glauser wrote: > > This sounds like a great idea. I was working with some tests today and it > would have been really useful to have some way to query the current > function/execution context. Seems like passing that through all lets would go > a long way, provided I'm reading this right. It would be very interesting to have a "maximally informative mode" and a "generate really tense code" mode. There is tradition behind such an idea. It would be especially interesting if the maximally informative mode had hooks tools could exploit. For example, Midje provides a hack where you can declare records in a way that the contained functions can be mocked: `defrecord-openly`. I expect almost no one uses it, even though it is no different than `defrecord` when in "production mode": it's too weird looking. But people would use it if ordinary defrecord methods weren't inlined during development. There's no *semantic* reason why parts of Clojure should *always* be closed to introspection-type actions. It's purely a matter of time constraints on the core team, which I am certainly not in a position to judge. How much core time should be spent on saving anonymous programmers time vs. saving cycles for anonymous apps running on the Amazon cloud? It's a tough tradeoff. Looking for 1/2-time employment as a Clojure programmer Latest book: /Functional Programming for the Object-Oriented Programmer/ https://leanpub.com/fp-oo -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
This sounds like a great idea. I was working with some tests today and it
would have been really useful to have some way to query the current
function/execution context. Seems like passing that through all lets would
go a long way, provided I'm reading this right.
On Friday, February 8, 2013 10:18:54 AM UTC-7, vemv wrote:
>
> Given that: a) fns can have names for debugging purposes, and b) data
> structures can have metadata, wouldn't it be a good idea to let let auto
> attach (where possible) the names of the bindings to their corresponding
> values?
>
> For example, the improved let I'm thinking of would translate this input:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn [] (throw (Exception.)))
> bar {:hello (/ 0 0)}]))
>
> to:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn foo [] (throw (Exception.)))
> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>
> This could be used to increase the precision of the stack traces, or in
> IDEs/editors for locating the exact source of an exception.
>
> Do you see such a mechanism being incorporated to clojure.core/let -
> should I open a ticket?
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
2013/2/8 vemv > Do you see such a mechanism being incorporated to clojure.core/let - > should I open a ticket? > Only for debugging and not before it has a proven implementation. For production, we actually want less metadata. At least in memory constrained environments like android. If you want to go forward with this, I'd recommend you create an implementation of let, that does this and get people to try it out. If it's a real aid in debugging, people will want it in core. If there are any issues to prevent it being useful, there is no need to clutter the ticket tracker. It's a mess already. -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: `let` to automatically add metadata / fn names?
I would find this very useful in several projects I'm working on, where the
library would be able to give better information on where the error is in
the user's code if this metadata was available.
On Friday, February 8, 2013 12:18:54 PM UTC-5, vemv wrote:
>
> Given that: a) fns can have names for debugging purposes, and b) data
> structures can have metadata, wouldn't it be a good idea to let let auto
> attach (where possible) the names of the bindings to their corresponding
> values?
>
> For example, the improved let I'm thinking of would translate this input:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn [] (throw (Exception.)))
> bar {:hello (/ 0 0)}]))
>
> to:
>
> (ns my.namespace)
>
> (defn do-it
> (let [foo (fn foo [] (throw (Exception.)))
> bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
>
> This could be used to increase the precision of the stack traces, or in
> IDEs/editors for locating the exact source of an exception.
>
> Do you see such a mechanism being incorporated to clojure.core/let -
> should I open a ticket?
>
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
`let` to automatically add metadata / fn names?
Given that: a) fns can have names for debugging purposes, and b) data
structures can have metadata, wouldn't it be a good idea to let let auto
attach (where possible) the names of the bindings to their corresponding
values?
For example, the improved let I'm thinking of would translate this input:
(ns my.namespace)
(defn do-it
(let [foo (fn [] (throw (Exception.)))
bar {:hello (/ 0 0)}]))
to:
(ns my.namespace)
(defn do-it
(let [foo (fn foo [] (throw (Exception.)))
bar ^{:origin :my.namespace/do-it$let$bar} {:hello (/ 0 0)}]))
This could be used to increase the precision of the stack traces, or in
IDEs/editors for locating the exact source of an exception.
Do you see such a mechanism being incorporated to clojure.core/let - should
I open a ticket?
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
