[viff-devel] Small VIFF language parser

[Janus Dam Nielsen]

--
Janus


Den 15/07/2008 kl. 12.16 skrev Martin Geisler:

> Janus Dam Nielsen <jdn at brics.dk> writes:
>
>> Den 11/07/2008 kl. 22.02 skrev Martin Geisler:
>>
>>> Right, good point! We should do that. Maybe a smart compiler could
>>> do the necessary deductions automatically? [...]
>>
>> I am not aware of any of-the-shelf technique for this, but it would
>> be a fun problem to solve.
>> Define a cost function:
>> Gamma(+) = 5
>> Gamma(-) = 5
>> Gamma(*) = 10
>>
>> I have no clue if these costs reflect the relative cost among the
>> operators, please correct me.
>
> I have never really measured the speed of additions/subtractions, but
> my guess is that they are a 100 or maybe a 1000 times faster than
> multiplications.
>
> And comparisons are about 500 times slower than multiplications.
>
>> Given the size of an expressions that naturally appear in programs I
>> think it is reasonable efficient to compute all permutations of the
>> expression under the distributive law and then pick any one of those
>> with the lowest cost under the Gamma cost function.
>>
>> This is worstcase exponential, but given the size of expressions
>> programmers are inclined to write in a program, then I don't think
>> it will be a problem.
>
> For single expression I guess not, but it should also work for chains
> of expressions (when possible):
>
>   x = a * b
>   y = a * c
>   z = x + y
>
> If x and y are not used, then z can be computed as a * (b + c). Was
> that already part of what you planned?
Yes I have been thinking about this as well, but I currently this as  
an extension we can pursue when we know how to deal with a single  
expression.
Even in such cases as above I guess that the size of expressions will  
be reasonable small. Lets see when we get some tests.


>> [...]
>>
>> If you are working in a language where you can redefine the
>> semantics of operators like * in Python you have to take that into
>> account as well, but it does not need to change the analysis
>> performed by the interpreter.
>
> Right, but I don't think we will want to give people that power?
No, you mentioned manipulating the Python AST and so I just wanted to  
let you know that this can also be done in Python.

>>> Depending on how much the SMCL compiler can do, it would be stupid
>>> to throw it away. But on the other hand we might be able to
>>> reimplement things quickly in Python from which we can work
>>> directly with the Python AST. I guess we need more comments from
>>> the Janus and Michael.
>>
>> You should see my progress report to see what the SMCL language and
>> compiler can do for you.
>
> I've printed the report and I hope I will have read it soon!
Nice, at least one more gets read my report :)

> Have you ever put up the source (and repository) somewhere? The
> nightly build linked from
>
>   http://www.daimi.au.dk/~fagidiot/simap/
>
> seems broken (as does many of the links on the blog...).
They haven't been maintained for a year now...

I have an svn repository at daimi
   /users/fagidiot/.SVNSMCL

I believe you can read from there.


> -- 
> Martin Geisler
> _______________________________________________
> viff-devel mailing list (http://viff.dk/)
> viff-devel at viff.dk
> http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk