
Metaprogramming – Julia Language - susi22
http://docs.julialang.org/en/latest/manual/metaprogramming/
======
breckinloggins
Elixir has similar mechanisms. It's great to see language designers explore
new ways of making a language homoiconic without pure s-expressions.

~~~
joe_the_user
The serious question I would have about non-s-expressions language is - while
they might be homoiconic by whatever definition, what makes them _easy to
parse_?

The thing that's appealing about s-expression languages is that code-as-data
is easy to do because parse, creating and modifying code is dead-easy. Is
there some still-very-easy algorithm for parsing things like infix operators
or does code-as-data depend on using the facilities of the language.

Edit: I can see Julia does this by reflection and macros. But I'm still
curious about the general issues and algorithms involved here.

~~~
draegtun
_> The serious question I would have about non-s-expressions language is -
while they might be homoiconic by whatever definition, what makes them easy to
parse?_

Rebol is very easy to parse. Here is a Rebol parser in 10 lines of Rebol:

    
    
        parse text blk-rule: [
            some [
                str:
                newline |
                #";" [thru newline | to end] new: (probe copy/part str new) |
                [#"[" | #"("] blk-rule |
                [#"]" | #")"] break |
                skip (set [value new] load/next str  probe :value) :new
            ]
        ]
    

ref:
[http://www.rebol.net/cookbook/recipes/0042.html](http://www.rebol.net/cookbook/recipes/0042.html)

~~~
joe_the_user
That is interesting and I'm getting back late on this.

But after mentally parsing _that_ , it seems all this is doing separating
blocks. What one would want to also do is to also scan operators, if one was
evaluating code or transforming it into an abstract syntax tree.

~~~
draegtun
I've been on holiday since I left my last reply so also getting back late on
this :)

Everything in Rebol is just _blocks_ of _words_ , where (in general)
expressions are evaluated from left to right; however, within each expression
evaluation occurs from right to left [1].

So (infix) operators are also just words and have no precedence order so they
just evaluate left to right (like Smalltalk) when parsed [2]...

    
    
      >> 1 + 2 * 3
      == 9
    

To enforce any precedence you use _paren!_ blocks [3], which are blocks that
get evaluated immediately.

    
    
      >> 1 + (2 * 3)
      == 7
    
    

refs:

[1] [http://www.rebol.com/r3/docs/guide/code-
eval.html](http://www.rebol.com/r3/docs/guide/code-eval.html)

[2] [http://www.rebol.com/r3/docs/concepts/math-
precedence.html](http://www.rebol.com/r3/docs/concepts/math-precedence.html)

[3]
[http://www.rebol.com/r3/docs/datatypes/paren.html](http://www.rebol.com/r3/docs/datatypes/paren.html)

------
andrewcooke
is the environment also available? are environments first class? it talks only
about expressions - the environment in which they are evaluated seems to be
implicit.

what could you do with first class environments? could you implement logic
variables and backtracking? something like oz?

also, i think julia is optionally typed? what's the type system like for
expressions? i saw an 'Any' in the link, which looked worryingly vague.

[having said all that, as a "scientific programmer", i am worrying more and
more that this is a language i really should be using]

[edit: thanks for the informative replies]

~~~
StefanKarpinski
Environments are intentionally _not_ first class: that particular dynamic
feature really sabotages optimization and can generally be worked around (e.g.
instead of letting the full environment escape, expose a closure that mutates
only what must be mutated).

Julia has optional type annotations, but this doesn't mean that code without
types is dynamic while code with types is static – all code is dynamic, the
type annotations just limit the set of types that values can have. It's a
subtle but important distinction.

------
terhechte
This is a copy from a comment I did in an earlier thread a couple of weeks
ago, but I think it still applies:

I really like Julia. I'm currently playing around with it whenever I find some
spare time. I don't see it as a competitor to R, I think it could well be
something along the lines of Python or Go. It is LLVM based, and already
really fast even though it is still a 0.2 and the JIT seems to have a lot of
room for optimisation. Whats more, it seems to offer just the right blend of
language features: - Easily include C libraries via a simple ffi [1] - It is
homoiconic like Lisp and thus allows for fantastic macro facilities [2] \- It
has solid parallel programming support via a Coroutines implementation (Tasks)
(similar to Goroutines as far as I can tell) \- It is a non-pure functional
language \- In contrast to Go it has generics, so functional constructs like
map, apply, drop, reduce, fold, partition & friends are already in there (or
can easily be implemented) [3] \- It has optional types, so that you can
assign types and the compiler will check for it and mark errors and will be
able to create optimised code, but you don't have to [4] \- Running external
programs is a joy [5] (Example: a=readall(`echo hello`)) The community seems
to be very alive. There's a simple web framework called "Morsel" and I've
recently set it up against a couple of contenders from the web framework
benchmark (cpoll-cppsp, phreeze, and some others), and even though it is still
a version 0.2, the performance for the json serialization benchmark would be
pretty close to Scalatra (I yet have to publish these numbers, will do so
soon). I really hope that Julia will grow, as I love the choices that went
into the design of the language, and it would be a shame if it would be only a
replacement for R instead of something much bigger, as it is such a nice
language.

(original:
[https://news.ycombinator.com/item?id=6172751](https://news.ycombinator.com/item?id=6172751))

[1] [http://docs.julialang.org/en/latest/manual/calling-c-and-
for...](http://docs.julialang.org/en/latest/manual/calling-c-and-fortran-
code/) [2]
[http://docs.julialang.org/en/latest/manual/metaprogramming/](http://docs.julialang.org/en/latest/manual/metaprogramming/)
[3] [http://docs.julialang.org/en/latest/stdlib/base/#general-
col...](http://docs.julialang.org/en/latest/stdlib/base/#general-collections)
[4]
[http://docs.julialang.org/en/latest/manual/types/](http://docs.julialang.org/en/latest/manual/types/)
[5] [http://docs.julialang.org/en/latest/manual/running-
external-...](http://docs.julialang.org/en/latest/manual/running-external-
programs/)

~~~
ScottBurson
There is a lot to like about Julia. It's obviously heavily influenced by
Common Lisp. I see offhand only one thing I really don't like: they are using
object semantics rather than value semantics for arrays. So for example:

    
    
      A = [0, 1, 2, 3]
      B = A
      A[1] = 2
      // now B[1] == 2
    

Their manual section on arrays says this:

 _In Julia, all arguments to functions are passed by reference. Some technical
computing languages pass arrays by value, and this is convenient in many
cases. In Julia, modifications made to input arrays within a function will be
visible in the parent function._

but as the above example shows, it's really the semantics of assignment we're
talking about here, not just that of function calls.

I believe that value semantics is easier to understand and less bug-prone,
particularly for nonexpert programmers. It can also be implemented well enough
that the small efficiency cost is worth paying in most cases. For one take on
how to do this, see my my FSet functional collections library for Common
Lisp[0]. For another, see the Clojure collection types.

[0] [http://common-lisp.net/project/fset](http://common-lisp.net/project/fset)

~~~
StefanKarpinski
Using value semantics for arrays is lovely in concept but ends up being really
annoying and impractical for writing really high-performance array code. This
is one of the most common complaints of library authors attempting to write
fast, efficient code in Matlab and is one of the many reasons why one ends up
having to write all performance-critical code in C using Matlab data
structures.

Clojure is reputed to get remarkable performance on a broad variety of data
structures, but I've had a hard time finding benchmarks comparing Clojure's
purely functional arrays with normal linearly indexed arrays – if you have
some references to such comparisons, I'd love to see them. In my experience,
nothing beats a plain old linearly indexed, mutable array when that's what you
need. Making that basic structure unavailable in a language intended for high-
performance numerical computing strikes me as utterly perverse.

~~~
ScottBurson
Oh, I wouldn't suggest making plain old mutable arrays _unavailable_. I
totally agree that library authors and sophisticated users need access to them
(and preferably not by dropping into C).

I just think the array and other collection types presented to users for
ordinary application-level programming should be functional. Mutable types
should stay in an "advanced topics" section of the manual.

~~~
marcosdumay
That's a bad an completely not intuitive trade-off for a language that is
expected to be fast.

I've first studied Julia today, but just by knowing its niche I already
expected it to use reference semantics, not value. It'd be quite confusing if
the examples demonstrated otherwise.

~~~
cgag
As long as it's not exceedingly difficult to drop down to using mutation,
having immutability by default is ridiculously nice. I don't think I
appreciated it fully until I used Clojure a significant amount, but using
languages with reference semantics feels disgusting now.

------
pekk
so many sigils, is Julia channeling Perl?

~~~
StefanKarpinski
The $ is only for splicing expressions into quoted code. Normal code that
isn't doing metaprogramming doesn't have any sigils in it. So, no, not really
channeling Perl.

~~~
susi22
Stephan, sorry for using this thread to ask you a question:

In the last ~5-10 year everything has moved more an more to the web. HTML5+JS
have pretty much replaced Flash,Java and other proprietary stuff. ~10 years
ago it was almost all PHP, ASP. Then came Python etc.

If you look at the speed that libraries were developed for node.js (and now
Go), it seems like the web-dev community can really push forward a technology
if it can be used to serve web content.

Q: Is there anything done in Julia, to actively attract web-devs for it? I
think that if Julia were "promoted" to also be perfect use as a web-server it
would attract much more developer and speed up library development.

Don't get me wrong, I'm not a web-dev, but would use Julia to replace MATLAB,
but I think it might be a good strategy for Julia to speed up the development
(especially for libraries).

~~~
zhemao
Not every language has to have webdev functionality shoehorned into it. I
hardly think that having more web developers involved would speed up the
development of the high quality scientific packages that Julia contributors
are already currently working on. The people the Julia community should focus
on attracting are data scientists and researchers in quantitative fields. That
being said, the guys at Hackerschool are working on a web framework for Julia
[https://github.com/hackerschool/Morsel.jl](https://github.com/hackerschool/Morsel.jl).

Oh and major kudos to the Julia team. This is a seriously awesome piece of
software. The decision to write most of the runtime in Julia itself and rely
on a solid JIT compiler and simple FFI to get the necessary performance was
very well thought out.

~~~
marcosdumay
I agree that web developers may not help building a scientific computation
language. But...

> Not every language has to have webdev functionality shoehorned into it.

I'm still in doubt about this. Web is the basic human I/O nowadays.

~~~
krichman
Web is the low-hanging fruit. Take a nice-looking language, add a web
framework, and developers can instantly do something useful in a language they
like. And as you say, it's a widespread need, so even a percentage of that
attention is quite a few people.

I think if a language really nailed a niche, especially a lucrative one like
scientific/numeric computing, it could be successful on those merits alone,
because it would get a large percentage of that niche.

------
alokv28
Nice to see!

I choose Mathematica over python for a lot of scientific/numerical computing
due to how "lisp-y" Mathematica is.

I'll be keeping a keen eye on Julia as well!

------
enupten
I love that Julia does so many things in so Lispy a way. I wish that other
languages like Lush received similar amounts of attention.

~~~
zem
i looked at lush several times, but somehow never got into it. some of the
things that put me off: the fact that sdl and opengl were not supported under
windows (my primary interest was in developing desktop applications and small
games), the dynamic scoping (i'm a scheme fan; not having lexical scoping
throughout just feels offputting) and the (real or perceived) lack of a strong
community. it did look like a great language, though, and i was rooting for it
despite never finding a good use for it myself.

~~~
enupten
I agree with the lexical scoping part (explains more or less why I don't use
Lush). Its a pity that there aren't any good numerical computing tools in
Common Lisp/Scheme. Oh, well.

~~~
klibertp
What about [http://docs.racket-lang.org/math/](http://docs.racket-
lang.org/math/) ?

~~~
enupten
I haven't looked into Racket-math, but this post: [http://lists.racket-
lang.org/users/archive/2013-January/0560...](http://lists.racket-
lang.org/users/archive/2013-January/056047.html) makes me wonder if Racket is
really up for non-toy numerics.

In contrast, SBCL uses tagless float arrays, so that array operations tend to
be cache friendly. With adequate declarations, numerical code in SBCL tends to
very fast (~1-3x C speed). I assume one can do the same with Bigloo and
Chicken scheme as well.

~~~
soegaard
On 04/22/2013 01:21 PM, Richard Cleis wrote: > Recently I used it for
estimating orientation parameters of > telescopes. Inputs are the locations of
stars, outputs are telescope > coordinates, parameters describe the
relationship of axes to each other > and to the earth.

[http://lists.racket-
lang.org/users/archive/2013-April/057487...](http://lists.racket-
lang.org/users/archive/2013-April/057487.html)

