Well a somewhat unique feature or R is automatic argument recycling, so
that when doing operations on dataframes, it's a lot easier to incorporate
data from outside of the dataframe into evaluation. Let's say you are doing
a stepwise logisitic growth model, like dP/dt = r*P*(1 - P/K). Let's say
Le samedi 25 juillet 2015 à 01:58 -0700, Brandon Taylor a écrit :
Well a somewhat unique feature or R is automatic argument recycling,
so that when doing operations on dataframes, it's a lot easier to
incorporate data from outside of the dataframe into evaluation. Let's
say you are doing a
Cool, workspace() seems very helpful. Yeah, I don't really understand
exactly what that code would look like either, because I'm not the most
familiar with time-series statistics. My point was that to work easily with
flexible models that mix environmental variables with dataframe variables,
Le jeudi 23 juillet 2015 à 15:31 -0700, Brandon Taylor a écrit :
I'm not saying inherent slowness will be particularly useful. I'm
saying environment access will be particularly useful. The point of
Julia is no compromise between speed and code-ability. If it is not
possible to integrate
Ok, maybe I was being harsh when I used the word mis-marketing. The post
here: http://julialang.org/blog/2012/02/why-we-created-julia/ specifically
mentions that one of Julia's goals is to be as easy for statistics as
R. Building a domain specific language is more difficult (but clearly not
I can understand that if you're used to building interfaces that use R's
non-standard evaluation and reified environments heavily, it can be
frustrating to not have those features. But I don't think that means that
you cannot build convenient and safe interfaces for data analysis.
On Fri, Jul 24,
I should give you a hard time about arguing from authority ;-), but I was
there at the same time and knew KMP, so I wouldn't want to argue too much
with him either, and I am in agreement with you about fexprs vs. macros,
and the equivalent issues in Julia.
On Friday, July 24, 2015 at 2:31:54
Le vendredi 24 juillet 2015 à 08:48 -0700, Brandon Taylor a écrit :
Ok, maybe I was being harsh when I used the word mis-marketing. The
post here: http://julialang.org/blog/2012/02/why-we-created-julia/ sp
ecifically mentions that one of Julia's goals is to be as easy for
statistics as R.
Macros seem to have a bunch of limitations. They can't be overloaded to take
advantage of Julia's typing system. Their functionality can somewhat mimic
evaluation within a function in its direct parent environment, but what if you
want to write functions within your macro, or macros inside your
Macros seem to have a bunch of limitations. They can't be overloaded to take
advantage of Julia's typing system. Their functionality can somewhat mimic
evaluation within a function in its direct parent environment, but what if you
want to write functions within your macro, or macros inside your
Lisp has already been down this path – fexprs
https://en.wikipedia.org/wiki/Fexpr were special forms with behavior
similar to R's functions, and they were deprecated in the 1980s in favor of
macros, https://en.wikipedia.org/wiki/Fexpr#Mainstream_use_and_deprecation:
His central objection was
Le vendredi 24 juillet 2015 à 11:21 -0700, Brandon Taylor a écrit :
Macros seem to have a bunch of limitations. They can't be overloaded
to take advantage of Julia's typing system. Their functionality can
somewhat mimic evaluation within a function in its direct parent
environment, but what
I agree, it would be very helpful to the discussion to have some examples
of the problems Brandon is looking to solve.
On Fri, Jul 24, 2015 at 3:09 PM, Milan Bouchet-Valat nalimi...@club.fr
wrote:
Le vendredi 24 juillet 2015 à 11:21 -0700, Brandon Taylor a écrit :
Macros seem to have a bunch
On Thu, Jul 23, 2015 at 4:23 PM, Brandon Taylor
brandon.taylor...@gmail.com wrote:
Will it cause a slowdown because there is a better way to do it or will it
cause a slowdown because something inherent about environment access?
Because if the second is the case, then it would be worth it, at
Will it cause a slowdown because there is a better way to do it or will it
cause a slowdown because something inherent about environment access?
Because if the second is the case, then it would be worth it, at least to
me.
On Thursday, July 23, 2015 at 11:13:14 AM UTC+8, Yichao Yu wrote:
On
What kind of mismarketing do you think is happening? I've been pretty clear on
my position (which seems to be representative of others here): environment
reification is a bad idea. It's basically just a tempting hack based on the
fact that slow language implementations often use dictionaries to
I'm not saying inherent slowness will be particularly useful. I'm saying
environment access will be particularly useful. The point of Julia is no
compromise between speed and code-ability. If it is not possible to
integrate environment access and speed, then I think that Julia is
mis-marketing
Ok, made some progress. Still having trouble with a _ENV_ not defined
error: how could it not be defined if it's a global variable??? Figuring
out argument passing is going to be tricky. Is this kind of system feasible
or is it going to cause huge slowdowns?
using DataFrames
import
On Wed, Jul 22, 2015 at 10:51 PM, Brandon Taylor
brandon.taylor...@gmail.com wrote:
Ok, made some progress. Still having trouble with a _ENV_ not defined error:
how could it not be defined if it's a global variable??? Figuring out
argument passing is going to be tricky. Is this kind of system
More to do:
Expressions would also have to be escaped from quoting.
If we can't scope types within dicts, it might be necessary to have special
markers for types so they can avoid being scoped.
I don't think that macros will be necessary anymore
On Wednesday, July 22, 2015 at 11:14:38 AM
Ok so I've got a good start. I bet John Myles White didn't think I could
get this far. Anyway, I'm getting caught up in defining my own escape
function. I'm getting lost in multiple layers of meta.
using DataFrames
import Base.convert
# allow inheritance from modules
function
I'm getting a cannot assign variables in other modules error.
On Tuesday, July 21, 2015 at 6:39:44 AM UTC+8, Yichao Yu wrote:
On Mon, Jul 20, 2015 at 6:35 PM, Brandon Taylor
brandon@gmail.com javascript: wrote:
Ok, a thought, Julia has an inbuilt idea of a module. Would it be
On Mon, Jul 20, 2015 at 9:41 PM, Brandon Taylor
brandon.taylor...@gmail.com wrote:
Dicts seem to work pretty well for this kind of thing.
For storage, maybe.
On Tuesday, July 21, 2015 at 9:38:36 AM UTC+8, Brandon Taylor wrote:
I'm getting a cannot assign variables in other modules error.
I should be possible to preprocess code such that everything is put into a
dict based on the name of enclosing function (and global variables will
just go into a dict called global).
On Tuesday, July 21, 2015 at 9:42:00 AM UTC+8, Brandon Taylor wrote:
Dicts seem to work pretty well for this
Although that would probably require nested dicts. Each would have a parent
dict, and if a lookup isn't found in the current dict, the parent dict
would be searched.
On Tuesday, July 21, 2015 at 9:53:50 AM UTC+8, Brandon Taylor wrote:
I should be possible to preprocess code such that
And there would need to be a special marker for them, such that if I'm in
function f, f[:a] won't get preprocessed as f[:f][:a]
On Tuesday, July 21, 2015 at 10:03:08 AM UTC+8, Brandon Taylor wrote:
Although that would probably require nested dicts. Each would have a
parent dict, and if a
Ok, a thought, Julia has an inbuilt idea of a module. Would it be possible
to hijack this functionality to provide pseudo-environments? That is, never
referring to anything that is not already in an explicit module? And also,
have a data-frame simply be a module?
On Friday, July 10, 2015 at
On Mon, Jul 20, 2015 at 6:35 PM, Brandon Taylor
brandon.taylor...@gmail.com wrote:
Ok, a thought, Julia has an inbuilt idea of a module. Would it be possible
to hijack this functionality to provide pseudo-environments? That is, never
referring to anything that is not already in an explicit
Hi Cedric,
a macroexpand shortcut for the REPL shouldn't be a big problem, I just
tried to prototype one and it seems to work fine:
https://github.com/meggart/julia/commit/73c96897572cedf10f74fd09907232c706bbdf48
Is there any special functionality/problems which I don't see that should
be
On Thursday, July 9, 2015 at 10:35:30 PM UTC-4, Brandon Taylor wrote:
To walk back in time, you could say something like: compile this like this
was is in line 8. Or compile this like this was in line 5. It seems like
Julia already has some of this functionality in macros. Internal
I don't know if you came across the vignette?
http://cran.r-project.org/web/packages/lazyeval/vignettes/lazyeval.html ?
dplyr uses lazyeval extensively,
see http://cran.r-project.org/web/packages/dplyr/vignettes/nse.html . The
cool thing about being able to incorporate this kind of thing in
Hmm, so the reason that macros are able to function is that they occur
before type computation? One solution might be to make scope annotations
that override defaults. Then, when eval is called, it optionally attaches
scope annotations to a given scope. Note that scope annotations should be
Hmm, so the reason that macros are able to function is that they occur
before type computation?
I don't know how best to respond to this question, but I will throw out
that staged functions are expanded after type information is known to the
compiler.
On Friday, July 10, 2015 at
Right now the best resources to learn how the compiler works are the
developer docs and Jeff's talk at JuliaCon last year.
http://docs.julialang.org/en/latest/#developer-documentation
https://www.youtube.com/watch?v=osdeT-tWjzk
(there were several more compiler-related talks this year;
On Friday, July 10, 2015 at 5:51:05 AM UTC-4, Fabian Gans wrote:
Hi Cedric,
a macroexpand shortcut for the REPL shouldn't be a big problem, I just
tried to prototype one and it seems to work fine:
https://github.com/meggart/julia/commit/73c96897572cedf10f74fd09907232c706bbdf48
Is there
On Thursday, July 9, 2015 at 10:25:24 AM UTC-4, Yichao Yu wrote:
Julia already have `macroexpand` so I guess you are talking about
editor/REPL feature?
Yeah. Emacs' macroexpand makes a big difference in usability for macros
IMO, otherwise one has to repeatedly cut and paste code in the
Environments are very natural in interpreted languages, but I'm not aware
of any fully-compiled language that supports them because they'd be a major
headache. I agree that macro behavior can be hard to predict. In Common
Lisp with Emacs, one can macroexpand any expression anywhere with one
On Thursday, July 9, 2015 at 4:14:32 PM UTC-4, Brandon Taylor wrote:
Ok, here's where I'm getting hung up. You said that the compiler figures
out the creation/lifetime of all variables at compile time. So does that
mean there's a list like:
a maps to location 0 and exists from line 3 to
gc optimizations aren't really the critical issue (although it is a
possible side-benefit). the big advantages are enforced type computability
(they cannot be accessed in ways that are invisible to inference) and
semantic purity (the variables are exactly those you see in the program,
plus any
To walk back in time, you could say something like: compile this like this
was is in line 8. Or compile this like this was in line 5. It seems like
Julia already has some of this functionality in macros. Internal variables
are compiled as if they were in local scope. But escaped expressions are
Is the issue garbage collection? That because by choosing variables
dynamically from a symbol table, you don't know which variables are going
to be used, so you don't know which data can be deleted early?
On Thursday, July 9, 2015 at 10:35:30 PM UTC-4, Brandon Taylor wrote:
To walk back in
Instead of speculating about how Julia's compiler handles scope, perhaps it
would be more fruitful to read the source code and learn how things
currently work?
Better still: why not spend some time trying to implement your feature
request? If you can manage to implement scope reification
Ok, here's where I'm getting hung up. You said that the compiler figures
out the creation/lifetime of all variables at compile time. So does that
mean there's a list like:
a maps to location 0 and exists from line 3 to line 9
b maps to location 1 and exists from line 7 to line 9
a maps to
https://en.wikipedia.org/wiki/Variable_(computer_science)#Scope_and_extent
On Thu, Jul 9, 2015 at 4:14 PM, Brandon Taylor brandon.taylor...@gmail.com
wrote:
Ok, here's where I'm getting hung up. You said that the compiler figures
out the creation/lifetime of all variables at compile time. So
Unless it did, in which case, I'm just uneducated.
On Thursday, July 9, 2015 at 6:31:03 PM UTC-4, Brandon Taylor wrote:
Ok, that was an interesting article, but it didn't really answer my
question.
On Thursday, July 9, 2015 at 4:20:45 PM UTC-4, Isaiah wrote:
Ok, that was an interesting article, but it didn't really answer my
question.
On Thursday, July 9, 2015 at 4:20:45 PM UTC-4, Isaiah wrote:
https://en.wikipedia.org/wiki/Variable_(computer_science)#Scope_and_extent
On Thu, Jul 9, 2015 at 4:14 PM, Brandon Taylor brandon@gmail.com
Le mercredi 08 juillet 2015 à 12:34 -0700, Brandon Taylor a écrit :
I was aware of those packages (though I hadn't read the discussions
referenced). Macros are great but they are incredibly difficult to
reason with concerning issues of scope (at least for me). Deifying
environments could
For example, here's a code snippet from R:
function (x, data) eval(x$expr, data, x$env)
x is an expression which contains an environment attribute. It is evaluated
first checking the bindings in data (data being a dataframe) and then
checing the bindings in x's environment.
On Wednesday, July
If scoping rules are too complicated and cause confusion, why are they
built into the base implementation of function?
On Wednesday, July 8, 2015 at 3:48:52 PM UTC-4, Milan Bouchet-Valat wrote:
Le mercredi 08 juillet 2015 à 12:34 -0700, Brandon Taylor a écrit :
I was aware of those packages
I was aware of those packages (though I hadn't read the discussions
referenced). Macros are great but they are incredibly difficult to reason
with concerning issues of scope (at least for me). Deifying environments
could solve all of these issues (and so much more) in one fell swoop.
On
It should be noted that in R, environments are simply pointers. They take
up no memory and shouldn't cause drastic slowdowns (I don't think).
On Wednesday, July 8, 2015 at 3:48:08 PM UTC-4, Brandon Taylor wrote:
For example, here's a code snippet from R:
function (x, data) eval(x$expr, data,
Le mercredi 08 juillet 2015 à 12:57 -0700, Brandon Taylor a écrit :
If scoping rules are too complicated and cause confusion, why are
they built into the base implementation of function?
What do you mean? Which function?
On Wednesday, July 8, 2015 at 3:48:52 PM UTC-4, Milan Bouchet-Valat
In fact, if environments could be reifyed, I'd go so far as to say that
Julia should have a separate syntax for a) evaluating an expression in its
defining environment and b) evaluating an expression in its evaluation
environment.
On Wednesday, July 8, 2015 at 3:53:29 PM UTC-4, Brandon Taylor
Some of these issues have been thought about fairly extensively by the
stats community in particular, precisely on account of the use cases you
cite:
https://github.com/JuliaStats/DataFrames.jl/pull/472
https://github.com/JuliaStats/DataFrames.jl/issues/504
I think that the matter is still
Le mercredi 08 juillet 2015 à 13:20 -0700, Brandon Taylor a écrit :
All functions.
Well, I don't know of any language which doesn't have scoping rules...
Anyway, I didn't say scoping rules are necessarily confusing, I was
only referring to R formulas. But according to the examples you posted,
For comparison, here is the analogous code from DataFramesMeta.
replace_syms(x, membernames) = x
function replace_syms(e::Expr, membernames)
if e.head == :call length(e.args) == 2 e.args[1] == :^
return e.args[2]
elseif e.head == :. # special case for :a.b
return
All functions.
On Wednesday, July 8, 2015 at 4:18:09 PM UTC-4, Milan Bouchet-Valat wrote:
Le mercredi 08 juillet 2015 à 12:57 -0700, Brandon Taylor a écrit :
If scoping rules are too complicated and cause confusion, why are
they built into the base implementation of function?
What do
On Wed, Jul 8, 2015 at 8:23 PM, Yichao Yu yyc1...@gmail.com wrote:
On Wed, Jul 8, 2015 at 7:48 PM, Brandon Taylor
brandon.taylor...@gmail.com wrote:
Hmm, maybe I'm confused about compilation vs interpretation. Let me
rephrase. Regardless of a how or when statement is evaluated, it must have
They must exist at runtime and at local scope. Evaluating a symbol is
impossible without a pool of defined symbols in various scopes to match it
to. Unless I'm missing something?
On Wednesday, July 8, 2015 at 7:26:27 PM UTC-4, Jameson wrote:
There are global symbol tables for static analysis
Hmm, maybe I'm confused about compilation vs interpretation. Let me
rephrase. Regardless of a how or when statement is evaluated, it must have
access at least to its parent environments to successfully resolve a symbol.
On Wednesday, July 8, 2015 at 7:34:09 PM UTC-4, Brandon Taylor wrote:
Edit: Hmm, so that means that any implementation of environments would have
to be handled in two separate ways: one by the compiler for non-global
scope, and one in run time for the special global system?]
On Wednesday, July 8, 2015 at 9:49:50 PM UTC-4, Brandon Taylor wrote:
Hmm, so that
There are global symbol tables for static analysis / reflection, but they
do not exist at runtime or for the local scope.
On Wed, Jul 8, 2015 at 7:06 PM Brandon Taylor brandon.taylor...@gmail.com
wrote:
Surely environments already exist somewhere inside Julia? How else could
you keep track of
On Wed, Jul 8, 2015 at 7:48 PM, Brandon Taylor
brandon.taylor...@gmail.com wrote:
Hmm, maybe I'm confused about compilation vs interpretation. Let me
rephrase. Regardless of a how or when statement is evaluated, it must have
access at least to its parent environments to successfully resolve a
Hmm, so that means that any implementation of environments would have to be
handled in to separate ways: one by the compiler for non-global scope, and
one in run time using a second for the special global system?]
On Wednesday, July 8, 2015 at 8:31:44 PM UTC-4, Yichao Yu wrote:
On Wed, Jul
*reifying. Deifying environments might not be the best idea.
On Wednesday, July 8, 2015 at 3:34:53 PM UTC-4, Brandon Taylor wrote:
I was aware of those packages (though I hadn't read the discussions
referenced). Macros are great but they are incredibly difficult to reason
with concerning
65 matches
Mail list logo
