|
|
Up |
|
|
  |
Author: Mark TarverMark Tarver Date: Jul 17, 2007 17:24
\Jon suggested that it would be good to implement some significant
programs in different functional languages for comparison. He
suggested interpreters for procedural languages like Basic.
QUOTE
There seems to be a great deal of interest from the functional
programming community in benchmarking. ..... I would also like to see
regexps, program evaluators (rewriters, interpreters and compilers)
and other benchmarks
UNQUOTE
Ok; here's a response - let's see if people want to try.
***********************************************************
The task is to implement an interpreter for a language Minim and run a
stock Minim program that adds two numbers x and y together where x =
100000 (10^5) and y = 100000 (10^5) and give the times.
***********************************************************
Minim is a very basic language - fairly close to assembly. Minim can
|
| Show full article (8.98Kb) |
|
| | 1466 Comments |
|
  |
Author: Matthias BlumeMatthias Blume Date: Jul 20, 2007 07:50
Mark Tarver ukonline.co.uk> writes:
> Qi does not need to do that with Minim because the Qi approach to
> typing is designed to be consistent with the Lisp approach to
> programming. No Qi/Lisp programmer will write a Minim lexer that is
> effectively nothing more than an identity function w.r.t. the input,
> and parsing is not needed in Qi because if the syntax is wrong the Qi
> type checker will tell him.
I think you are being unfair here. Clearly, you designed the language
specifically so that it can be parsed trivially using Lisp.
(Well, at least as long as you allow an extra pair of parentheses
around your program -- something that the original grammar you posted
did not.)
And, strangely, you don't even stick to that syntax but use a
different one in your Qi implementation...
> Your adopted religion requires you to operate in this way; like having
> to eat cold boiled spinach on Sunday. But I have no appetite for
> eating cold spinach; this is why I left languages like ML, OCaml and
> Haskell behind a long time ago.
|
| Show full article (1.56Kb) |
|
| | 6 Comments |
|
  |
Author: Jon HarropJon Harrop Date: Jul 20, 2007 07:54
Mark Tarver wrote:
> The problem here I think is the OCaml technology...
Allow me to cripple the OCaml, making it as featureless as the Lisp:
module Bindings = Map.Make(String)
let set m x y = Bindings.add x y m
let get m x = Bindings.find x m
let tags_of program =
let aux (pc, tags) = function
| `Tag t -> pc+1, Bindings.add t pc tags
| _ -> pc+1, tags in
let _, tags = Array.fold_left aux (0, Bindings.empty) program in
tags
let eval vars = function
| `Lit n -> n
| `Var v -> get vars v
|
| Show full article (2.15Kb) |
| no comments |
|
  |
Author: Jon HarropJon Harrop Date: Jul 20, 2007 08:01
Matthias Blume wrote:
> Mark Tarver ukonline.co.uk> writes:
>> Qi does not need to do that with Minim because the Qi approach to
>> typing is designed to be consistent with the Lisp approach to
>> programming. No Qi/Lisp programmer will write a Minim lexer that is
>> effectively nothing more than an identity function w.r.t. the input,
>> and parsing is not needed in Qi because if the syntax is wrong the Qi
>> type checker will tell him.
>
> I think you are being unfair here...
It would be unfair to compare the similar-sized Lisp and OCaml
implementations when only the OCaml implements a lexer and parser. Provided
you strip the lexer and parser from the OCaml, I think it is fair. The
OCaml remains several times faster and is now several times shorter as
well.
|
| Show full article (1.23Kb) |
| no comments |
|
  |
Author: Andy FreemanAndy Freeman Date: Jul 20, 2007 10:09
On Jul 20, 8:01 am, Jon Harrop ffconsultancy.com> wrote:
> Now I can only
> assume that it is prohibitively difficult to implement such trivial
> functionality correctly in Lisp.
Great!
Now go tell other people how OCaml/F# are superior to lisp and leave
those of us who noticed that the above is nothing more than a claim
about your limitations in peace.
-andy
|
| |
| no comments |
|
  |
Author: Mark TarverMark Tarver Date: Jul 20, 2007 11:13
On 20 Jul, 15:50, Matthias Blume wrote:
> Mark Tarver ukonline.co.uk> writes:
>> Qi does not need to do that with Minim because the Qi approach to
>> typing is designed to be consistent with the Lisp approach to
>> programming. No Qi/Lisp programmer will write a Minim lexer that is
>> effectively nothing more than an identity function w.r.t. the input,
>> and parsing is not needed in Qi because if the syntax is wrong the Qi
>> type checker will tell him.
>
> I think you are being unfair here. Clearly, you designed the language
> specifically so that it can be parsed trivially using Lisp.
> (Well, at least as long as you allow an extra pair of parentheses
> around your program -- something that the original grammar you posted
> did not.)
> And, strangely, you don't even stick to that syntax but use a
> different one in your Qi implementation...
>
>> Your adopted religion requires you to operate in this way; like having
>> to eat cold boiled spinach on Sunday. But I have no appetite for
>> eating cold spinach; this is why I left languages like ML, OCaml and ...
|
| Show full article (2.25Kb) |
| no comments |
|
  |
Author: Mark TarverMark Tarver Date: Jul 20, 2007 12:16
On 20 Jul, 16:01, Jon Harrop ffconsultancy.com> wrote:
> Matthias Blume wrote:
>> Mark Tarver ukonline.co.uk> writes:
>>> Qi does not need to do that with Minim because the Qi approach to
>>> typing is designed to be consistent with the Lisp approach to
>>> programming. No Qi/Lisp programmer will write a Minim lexer that is
>>> effectively nothing more than an identity function w.r.t. the input,
>>> and parsing is not needed in Qi because if the syntax is wrong the Qi
>>> type checker will tell him.
>
>> I think you are being unfair here...
>
> It would be unfair to compare the similar-sized Lisp and OCaml
> implementations when only the OCaml implements a lexer and parser. Provided
> you strip the lexer and parser from the OCaml, I think it is fair. The
> OCaml remains several times faster and is now several times shorter as
> well.
>
> I think it is a shame that Mark backtracked from a description of the
> grammar only to hard-code the interpreted program in the interpreter. I ...
|
| Show full article (3.59Kb) |
| no comments |
|
  |
Author: Mark TarverMark Tarver Date: Jul 20, 2007 14:43
On 19 Jul, 20:47, Joachim Durchholz durchholz.org> wrote:
> Mark Tarver schrieb:
>
>> Actually, thats easy in Lisp because Lisp includes many 'impure'
>> procedural constructions. I doubt it would be so easy to do in a pure
>> functional language.
>
> Quite to the contrary.
> They don't have to do aliasing or dataflow analysis to do that kind of
> optimization. I'd expect that kind of optimization to happen far more
> early in the development cycle of a compiler, and that it will stay more
> aggressive throughout the compiler's lifetime.
>
> Regards,
> Jo
\I don't reckon so; Lisp is a very easy target for *compiling* Minim.
Here's the code which runs under the Qi environment. It takes a Minim
program in one file and outputs the corresponding Lisp to be LOADed
into Qi.\
|
| Show full article (2.28Kb) |
| no comments |
|
  |
Author: Jon HarropJon Harrop Date: Jul 20, 2007 17:06
Mark Tarver wrote:
> Actually it is a doddle in this case. I didn't attach vast importance
> to this issue. OK
>
> (define load-and-run-minim
> File -> (time (run (read-file File)))
>
> will do the trick. This runs the following program in a file.
>
> (print "Add x and y")
> ...
> nl
>
> I've said before, and I'll repeat it again, that the Qi type checker
> is doing the parsing here.
This is the input program according to the task that you set and the grammar
that you provided:
|
| Show full article (1.27Kb) |
| no comments |
|
  |
|
|
  |
Author: Matthias BlumeMatthias Blume Date: Jul 20, 2007 19:02
Jon Harrop ffconsultancy.com> writes:
> Mark Tarver wrote:
>> The problem here I think is the OCaml technology...
>
> Allow me to cripple the OCaml, making it as featureless as the Lisp:
>
> module Bindings = Map.Make(String)
>
> let set m...
|
| Show full article (2.10Kb) |
| no comments |
|
|
|
|