Thanks for the explanation. My assumption was that evaling a compiled
function would not work.
When I tried it I was really surprised that it did for some simple cases.
I think it would be better if it never worked. This inconsistent behavior
is confusing.
Anyway, the workaround I found is to
On 16/10/12 13:20, Michael Gardner wrote:
On Oct 16, 2012, at 5:16 AM, Jim foo.bar wrote:
so you're saying that if I write a for-loop in Java that populates an array
with constants from 1-1 and then a 2nd loop to add them up, it would happen
at compile-time and i would get the same timing
On Oct 16, 2012, at 5:16 AM, Jim foo.bar wrote:
> so you're saying that if I write a for-loop in Java that populates an array
> with constants from 1-1 and then a 2nd loop to add them up, it would
> happen at compile-time and i would get the same timing-result?
Maybe, maybe not. Compilers a
"Jim foo.bar" writes:
Hi Jim,
>> One example that does things like constant-folding like macrology is
>> the unit conversion macro in Let Over Lambda that compiles to
>> constants if both value and unit are given literally (recursively).
>
> unit conversion! this is exactly what i had in mind!!!
On 16/10/12 11:49, Tassilo Horn wrote:
One example that does things like constant-folding like macrology is the
unit conversion macro in Let Over Lambda that compiles to constants if
both value and unit are given literally (recursively).
unit conversion! this is exactly what i had in mind!!! wh
"Jim - FooBar();" writes:
>> You add the numbers at compile time, and then time how long it takes
>> to...do nothing to them, at runtime. You are comparing N to zero, not
>> to some smaller factor of N.
>
> yes but this seems almost unbelievable...i mean for simple numeric
> operations this littl
On 16/10/12 03:50, Michael Gardner wrote:
On Oct 15, 2012, at 7:45 PM, Andy Fingerhut wrote:
For the case of arithmetic on compile-time constants, I believe that many C,
Java, etc. compilers already perform the arithmetic at compile time.
Known as "constant folding", yes.
so you're saying
On Oct 15, 2012, at 7:45 PM, Andy Fingerhut wrote:
> For the case of arithmetic on compile-time constants, I believe that many C,
> Java, etc. compilers already perform the arithmetic at compile time.
Known as "constant folding", yes.
--
You received this message because you are subscribed to
On 16/10/12 01:45, Andy Fingerhut wrote:
On Oct 15, 2012, at 5:41 PM, Jim - FooBar(); wrote:
On 15/10/12 22:44, Alan Malloy wrote:
You add the numbers at compile time, and then time how long it takes
to...do nothing to them, at runtime. You are comparing N to zero, not
to some smaller factor o
On Oct 15, 2012, at 5:41 PM, Jim - FooBar(); wrote:
> On 15/10/12 22:44, Alan Malloy wrote:
>>
>> You add the numbers at compile time, and then time how long it takes
>> to...do nothing to them, at runtime. You are comparing N to zero, not
>> to some smaller factor of N.
>>
>
> yes but this se
On 15/10/12 22:44, Alan Malloy wrote:
On Oct 15, 1:07 pm, "Jim - FooBar();" wrote:
On 15/10/12 19:42, Ben Smith-Mannschott wrote:
If the distinction I'm trying to make is not clear to you, I'd suggest
having a look athttp://www.infoq.com/presentations/Clojure-Macros (It
does a good job explor
On Oct 15, 1:07 pm, "Jim - FooBar();" wrote:
> On 15/10/12 19:42, Ben Smith-Mannschott wrote:
>
> > If the distinction I'm trying to make is not clear to you, I'd suggest
> > having a look athttp://www.infoq.com/presentations/Clojure-Macros (It
> > does a good job exploring these kinds of distinct
On 15/10/12 19:42, Ben Smith-Mannschott wrote:
If the distinction I'm trying to make is not clear to you, I'd suggest
having a look athttp://www.infoq.com/presentations/Clojure-Macros (It
does a good job exploring these kinds of distinctions as it's vital to
have an accurate mental model of how
I agree with Lee. Everything that works in standard clojure should also
work in an eval.
Jonathan
On Mon, Oct 15, 2012 at 8:11 PM, Lee Spector wrote:
> On Oct 15, 2012, at 12:51 PM, Alan Malloy wrote:
>
> > Evaluating function literals is not intended to work; that it works
> > for non-closure
On Oct 15, 2012, at 2:42 PM, Ben Smith-Mannschott wrote:
>
> I think you're confusing:
>
> (eval (list '(fn [x] x) 1))
>
> with:
>
> (eval (list (fn [x] x) 1))
>
> In both cases, eval is being passed a list of two items. The first
> element of the list differs, however:
>
> In the first case
On Mon, Oct 15, 2012 at 8:11 PM, Lee Spector wrote:
> On Oct 15, 2012, at 12:51 PM, Alan Malloy wrote:
>
>> Evaluating function literals is not intended to work; that it works
>> for non-closure functions should be treated as a coincidence.
>
> Really? Eval "Evaluates the form data structure (not
On Oct 15, 2012, at 12:51 PM, Alan Malloy wrote:
> Evaluating function literals is not intended to work; that it works
> for non-closure functions should be treated as a coincidence.
Really? Eval "Evaluates the form data structure (not text!) and returns the
result." Why would certain things lik
Evaluating function literals is not intended to work; that it works
for non-closure functions should be treated as a coincidence.
On Oct 15, 2:19 am, Gergely Szabó wrote:
> Hello,
>
> could someone please explain the behavior that is shown in the gist below?
>
> https://gist.github.com/3891587
>
Evaluating function literals is not intended to work; that it works
for non-closure functions should be treated as a coincidence.
On Oct 15, 2:19 am, Gergely Szabó wrote:
> Hello,
>
> could someone please explain the behavior that is shown in the gist below?
>
> https://gist.github.com/3891587
>
19 matches
Mail list logo
