One of the strengths of Mathematica's pattern matching system is the
ability for structural matching, e.g. to match a list where the second
element is a real number. This is something that is not (yet?) possible
with Julia's dispatch. It would be nice to be able to write something like
```Julia
function f(x::Expr where x.args::Tuple{T, Real, ...})
```
(with a more concise syntax) to mimic this.
-erik
On Thu, Sep 1, 2016 at 7:10 PM, Chris Rackauckas <rackd...@gmail.com> wrote:
> I think types+dispatch is the right way to go. It's what Julia is founded
> upon, and it's what leads to really fast computations. A fast type/dispatch
> based symbolic system for Julia and in pure Julia would be a huge asset.
> And while the post said not to mention the front end, when talking about
> Mathematica you have to talk about the front end. The only reason why I use
> it over other CAS' is because that notebook looks like math. Until someone
> implements something like that in Julia, I will always have a reason to
> open up Mathematica.
>
>
> On Thursday, September 1, 2016 at 3:22:12 PM UTC-7, lapeyre....@gmail.com
> wrote:
>>
>>
>>
>> On Thursday, January 23, 2014 at 11:47:11 PM UTC+1, Акатер Дима wrote:
>>>
>>> It's mentioned here http://julialang.org/blog/2012
>>> /02/why-we-created-julia/ that Mathematica was one of the programs that
>>> inspired Julia. How does Julia compare to Mathematica's language?
>>>
>>> To make the question more specific,
>>>
>>> - it's about languages, not implementations, so Mathematica's FrontEnd
>>> capabilities are irrelevant (and it's also not about “which one is faster”)
>>> - it's not about free vs non-free
>>> - it's not about communities and support
>>> - it's not about anything related to OOP (feel free to write about,
>>> sure, but I will probably be very passive in discussions concerning OOP)
>>>
>>> - it's about the languages' most high-level features, like
>>> meta-programming, macros, interactions with other languages and the way it
>>> treats types
>>>
>>> For example, Wolfram language (which is now the name of Mma's core
>>> language), implements meta-programming capabilities via term-rewriting and
>>> Hold. It provides some foreign-language interfaces via MathLink (which
>>> could be WolframLink already) and also has SymbolicC. It is untyped and
>>> proud of it; types can be implemented easily but they are of little
>>> practical need in the absence of compiler.
>>>
>>>
>> - it's also about the languages' most distinctive features: are there
>>> things Julia has that WL does not have? (Which means adding them to WL
>>> would require reimplementing Julia in WL, much in spirit of Greenspun's
>>> tenth rule.)
>>>
>>> I think it is easier to go the other direction and implement
>> something like Mma in Julia. This is what I have done here:
>>
>> https://github.com/jlapeyre/SJulia.jl
>>
>> I think Julia is uniquely well suited for implementing a Mma-like
>> language. I agree with the comment below that Mma is designed in part to
>> appeal to non-programmers. A large part of its appeal is that it collects a
>> lot of mathematics functionality that is hard to find elsewhere... all
>> kinds of algorithms and special functions. Many of these can be used with
>> one or a few lines of code. I kept the non-programmer in mind when writing
>> SJulia.
>>
>> The question of what kind of type system a language has is somewhat
>> polemic. In some sense, Mma is untyped. There is no hierarchy in
>> expressions; they all have a head and arguments. I think hierarchies of
>> mathematical objects are not well represented by hierarchies of programming
>> language types. Which hierarchy a particular mathematical object belongs to
>> and its exact definition is very fluid. Languages like Mma that attach no
>> inherent meaning to expressions are well suited for mathematics for
>> scientists and engineers. A matrix is an expression with head 'List' each
>> of whose elements is an expression of fixed length with head 'List'. Still
>> types creep into Mma in various ways.
>>
>> Some people prefer types to play a larger role in symbolic computation.
>> For instance:
>>
>> http://www.sympy.org/en/index.html
>>
>> https://github.com/jverzani/SymPy.jl
>>
>> http://nemocas.org/
>>
>> Whether to use types depends in part on the domain of the language. But
>> even for rather general math capabilities, language design determines in
>> part the role of types. Sympy (in python and Julia) aim to add symbolic
>> computation capability to Julia. They are more 'typed' than Mma and
>> SJulia. But, it seems that python sympy is hybrid in this respect and also
>> supports generic expressions.
>>
>>
>>> To provide a starting point, here is the definition of type in Julia
>>> from documentation http://docs.julialang.org/en/l
>>> atest/manual/metaprogramming/
>>>
>>> type Expr
>>> head::Symbol
>>> args::Array{Any,1}
>>> typend
>>>
>>>
>>> Maybe there's a typo in docs (line 4) but it doesn't really matter. What
>>> do Julia users do, for example, to avoid boilerplate code defining lots of
>>> types? I understand how to avoid writing boilerplate definitions in WL: it
>>> may not be easy but at least I know where to begin in case I need a program
>>> that would write new definitions or update existing ones.
>>>
>>
--
Erik Schnetter <schnet...@gmail.com>
http://www.perimeterinstitute.ca/personal/eschnetter/
