Does anyone know of a suitably simple interpreter written in Lisp (say <
2kLOC) than I can port to OCaml in order to compare the effort required to
write an interpreter in these languages and the resulting performance?
I've had a little Google and found this BASIC interpreter:
http://www.informatimago.com/develop/lisp/small-cl-pgms/
but it doesn't seem to leverage features than Lisp has and OCaml lacks (i.e.
code as data and arbitrary macros) as much as it could.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Does anyone know of a suitably simple interpreter written in Lisp (say <
> 2kLOC) than I can port to OCaml in order to compare the effort required to
> write an interpreter in these languages and the resulting performance?
>
> I've had a little Google and found this BASIC interpreter:
>
> http://www.informatimago.com/develop/lisp/small-cl-pgms/
>
> but it doesn't seem to leverage features than Lisp has and OCaml lacks (i.e.
> code as data and arbitrary macros) as much as it could.
Writing an inefficient interpreter like that is going to be minimally
easier in Lisp than writing it in any other language that supports data
structures and functions. You'll have to roll your own symbol table.
Big deal.
But why would you ever want to write an interpreter that can't
communicate with the outside world (here, the host language)?
Writing a *useful* interpreter is where Lisp shines. Just compare
pre-CLOS lisp and CLOS lisp to C and C++. Because CLOS is written as a
set of macros that transform CLOS code into pre-CLOS code, pre-CLOS lisp
functions, like mapcar, can use CLOS generic functions with no change to
the source code. Existing C code, like qsort, can't use C++ virtual
functions without the programmer being forced to write a compatibility
layer for each function he wants to use!
How about porting Cells or AspectL to OCaml?
-- MJF
M Jared Finder wrote:
> Writing an inefficient interpreter like that is going to be minimally
> easier in Lisp than writing it in any other language that supports data
> structures and functions. You'll have to roll your own symbol table.
> Big deal.
Right, that's what I thought.
> But why would you ever want to write an interpreter that can't
> communicate with the outside world (here, the host language)?
I've written interpreters and compilers for DSLs for graphical or
mathematical programming. I never wanted them to "communicate with the
outside world" in the way that you suggest. I can see how that might be
useful, particularly if you want to extend Lisp, but that isn't something
that would have been useful for me.
> Writing a *useful* interpreter is where Lisp shines. Just compare
> pre-CLOS lisp and CLOS lisp to C and C++. Because CLOS is written as a
> set of macros that transform CLOS code into pre-CLOS code, pre-CLOS lisp
> functions, like mapcar, can use CLOS generic functions with no change to
> the source code. Existing C code, like qsort, can't use C++ virtual
> functions without the programmer being forced to write a compatibility
> layer for each function he wants to use!
Sure. The problem here is that, although such things may be useful to a Lisp
programmer, they are useless to everyone else because they are entirely
Lisp-oriented.
My idea of something useful is quite different - I want it to be useful for
non-Lisp (and non-ML) people. So a program to execute BASIC or Logo
programs would be ideal, for example.
The target language must be removed from both Lisp and ML in order to remove
bias. Writing a Lisp interpreter or syntax extension is clearly much easier
in Lisp, just as writing an ML interpreter is much easier in ML.
> How about porting Cells or AspectL to OCaml?
Those both seem to be syntax extensions to Lisp. I'm much more interested in
developing a completely separate language (e.g. a DSL) on top of Lisp.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> The target language must be removed from both Lisp and ML in order to remove
> bias. Writing a Lisp interpreter or syntax extension is clearly much easier
> in Lisp, just as writing an ML interpreter is much easier in ML.
What do you care about (or mean by) "bias?" Do you not trust your own
judgement? Or are you doing this comparison for some client and are
worried about being called a Lispnik? What audience is going to judge
your level of impartiality?
Would you ask an Olympic sprinter to crawl so that you can compare his
athletic prowess against an infant "without bias"? The infant can't
even walk upright, much less run, but that does not make the comparison
unfair; it is the *essential point* of the comparison.
Writing "interpreters" from scratch is a totally artificial task, which
is one reason it is favored in computer science courses, and is similar
to the writing of Scheme implementations.
The real task of programming is to take input data, and generate
meaningful output, with the most efficient use of human effort. Lisp
excels in the reduction of human effort, by allowing its control
structures to be extended to include new problem domains, meaning that
human programmers can describe the computing task in terms specific to
the problem domain *without* giving up the expressive power that
already exists in the language.
For crying out loud, just learn Lisp on its own terms, or don't learn
Lisp, stay happy using your languages of choice, and keep quiet about
it.
Jon Harrop wrote:
> My idea of something useful is quite different - I want it to be useful for
> non-Lisp (and non-ML) people. So a program to execute BASIC or Logo
> programs would be ideal, for example.
Why would a BASIC interpreter written in Lisp not be useful? Compile a
bundle for Windows, Linux, and the Mac and publish it...
> The target language must be removed from both Lisp and ML in order to remove
> bias. Writing a Lisp interpreter or syntax extension is clearly much easier
> in Lisp, just as writing an ML interpreter is much easier in ML.
Lisp in Lisp sure, as you can reuse a lot, but why should ML be easier
to interpret in ML?
--
Some people like democracy. That's because it does whatever the
majority wants, and because they happen to be part of that majority.
"Do you want the Total War?"
Ulrich Hobelmann wrote:
> Jon Harrop wrote:
>> My idea of something useful is quite different - I want it to be useful
>> for non-Lisp (and non-ML) people. So a program to execute BASIC or Logo
>> programs would be ideal, for example.
>
> Why would a BASIC interpreter written in Lisp not be useful?
It would be ideal. The particular BASIC interpreter that I stumbled upon
doesn't appear to leverage Lisp as much as it could though.
>> The target language must be removed from both Lisp and ML in order to
>> remove bias. Writing a Lisp interpreter or syntax extension is clearly
>> much easier in Lisp, just as writing an ML interpreter is much easier in
>> ML.
>
> Lisp in Lisp sure, as you can reuse a lot, but why should ML be easier
> to interpret in ML?
It is much easier to write a pattern matcher using pattern matching, for
example.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Hello Jon,
On Mon, 26 Sep 2005 15:34:26 +0100
Jon Harrop <······@jdh30.plus.com> wrote:
> ...
> Those both seem to be syntax extensions to Lisp. I'm much more
> interested in developing a completely separate language (e.g. a DSL) on
> top of Lisp.
Take a look at XPath/XSLT/XQuery. They are simple languages with
hardcore surprises.
A shameless plug for context links:
Using DSLs on top of Scheme VM
http://uucode.com/blog/2005/06/05/towards-gttse-2005/
My research wiki
http://xmlhack.ru/protva/xquery/index.php/
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy
> http://www.ffconsultancy.com
--
Oleg Paraschenko ····@ http://uucode.com/
http://uucode.com/blog/ Generative Programming, XML, TeX, Scheme
Jon Harrop wrote:
> Sure. The problem here is that, although such things may be useful to a Lisp
> programmer, they are useless to everyone else because they are entirely
> Lisp-oriented.
>
> My idea of something useful is quite different - I want it to be useful for
> non-Lisp (and non-ML) people. So a program to execute BASIC or Logo
> programs would be ideal, for example.
Okay... use flex to lex the input into tokens, and bison to
build the syntax tree. About a six-line routine will
recursively traverse the tree outputting s-expressions.
I think Lispy equivalents of all these exist, but this
is not Lisp's department in terms of language extension,
and it's a separate program from the interpreter anyway.
In Lisp, you write functions and macros to make the different
kinds of nodes in the syntax tree mean what you want them to
mean in your language.
Finally, suck the s-expressions into Lisp and execute them.
Bear
Ray Dillinger wrote:
> Okay... use flex to lex the input into tokens, and bison to
> build the syntax tree. About a six-line routine will
> recursively traverse the tree outputting s-expressions.
> I think Lispy equivalents of all these exist, but this
> is not Lisp's department in terms of language extension,
> and it's a separate program from the interpreter anyway.
>
> In Lisp, you write functions and macros to make the different
> kinds of nodes in the syntax tree mean what you want them to
> mean in your language.
>
> Finally, suck the s-expressions into Lisp and execute them.
Right. I've started playing around with this and my current Lisp code is
much more concise and much faster than the OCaml and SML. Interestingly,
MLton-compiled SML is 5x faster than OCaml.
I'm also interested in trying this on rewrite systems. I don't think Lisp
will do so well here (I'm not sure though) as you can't compile so much
into s-exprs for evaluation. The Lisp can probably be developed into a JIT
compiler more easily though.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Does anyone know of a suitably simple interpreter written in Lisp (say <
> 2kLOC) than I can port to OCaml in order to compare the effort required to
> write an interpreter in these languages and the resulting performance?
>
> I've had a little Google and found this BASIC interpreter:
>
> http://www.informatimago.com/develop/lisp/small-cl-pgms/
>
> but it doesn't seem to leverage features than Lisp has and OCaml lacks
> (i.e. code as data and arbitrary macros) as much as it could.
and I don't mean a Lisp interpreter written in Lisp... :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
In article <·························@ptn-nntp-reader01.plus.net>,
Jon Harrop <······@jdh30.plus.com> wrote:
> Jon Harrop wrote:
> > Does anyone know of a suitably simple interpreter written in Lisp (say <
> > 2kLOC) than I can port to OCaml in order to compare the effort required to
> > write an interpreter in these languages and the resulting performance?
> >
> > I've had a little Google and found this BASIC interpreter:
> >
> > http://www.informatimago.com/develop/lisp/small-cl-pgms/
> >
> > but it doesn't seem to leverage features than Lisp has and OCaml lacks
> > (i.e. code as data and arbitrary macros) as much as it could.
>
> and I don't mean a Lisp interpreter written in Lisp... :-)
Then you have completely missed the point (not that that wasn't already
quite clear).
You can either see examples that leverage Lisp's features, or you can
see examples of Lisp applied to problems where Lisp's features do not
provide much leverage. You cannot have both.
rg
Ron Garret wrote:
> Then you have completely missed the point (not that that wasn't already
> quite clear).
>
> You can either see examples that leverage Lisp's features, or you can
> see examples of Lisp applied to problems where Lisp's features do not
> provide much leverage. You cannot have both.
I want to see how Lisp's features help with real problems. Specifically,
when writing a program to execute programs written in a completely
different language.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
In article <·························@ptn-nntp-reader04.plus.net>,
Jon Harrop <······@jdh30.plus.com> wrote:
> Ron Garret wrote:
> > Then you have completely missed the point (not that that wasn't already
> > quite clear).
> >
> > You can either see examples that leverage Lisp's features, or you can
> > see examples of Lisp applied to problems where Lisp's features do not
> > provide much leverage. You cannot have both.
>
> I want to see how Lisp's features help with real problems. Specifically,
> when writing a program to execute programs written in a completely
> different language.
You still don't get it. What you are asking for is similar to saying:
"I want to see how a Ferrari performs. Specifically, I want to see how
well it does when you take it off-road."
rg
Jon Harrop wrote:
> Ron Garret wrote:
>
>>Then you have completely missed the point (not that that wasn't already
>>quite clear).
>>
>>You can either see examples that leverage Lisp's features, or you can
>>see examples of Lisp applied to problems where Lisp's features do not
>>provide much leverage. You cannot have both.
>
> I want to see how Lisp's features help with real problems. Specifically,
> when writing a program to execute programs written in a completely
> different language.
You mean something like http://www.weitz.de/rdnzl/ or
http://jfli.sourceforge.net/ ;-)
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza wrote:
> You mean something like http://www.weitz.de/rdnzl/ or
> http://jfli.sourceforge.net/ ;-)
Now you're tying to misinterpret what I'm saying (pun intended). ;-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Pascal Costanza wrote:
>
>>You mean something like http://www.weitz.de/rdnzl/ or
>>http://jfli.sourceforge.net/ ;-)
>
> Now you're tying to misinterpret what I'm saying (pun intended). ;-)
...just when you said that you want to see how real problems are solved.
OK, let's get back to imaginary problems...
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Jon Harrop wrote:
> Does anyone know of a suitably simple interpreter written in Lisp (say <
> 2kLOC) than I can port to OCaml in order to compare the effort required to
> write an interpreter in these languages and the resulting performance?
>
> I've had a little Google and found this BASIC interpreter:
>
> http://www.informatimago.com/develop/lisp/small-cl-pgms/
>
> but it doesn't seem to leverage features than Lisp has and OCaml lacks (i.e.
> code as data and arbitrary macros) as much as it could.
Try Pseudoscheme: http://mumble.net/~jar/pseudoscheme/
It's not actually an interpreter but rather a compiler, but I think it
shows well how to embed a different language in Common Lisp.
If it has to be an interpreter, why?
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza wrote:
> Jon Harrop wrote:
> > Does anyone know of a suitably simple interpreter written in Lisp (say <
> > 2kLOC) than I can port to OCaml in order to compare the effort required to
> > write an interpreter in these languages and the resulting performance?
> >
> > I've had a little Google and found this BASIC interpreter:
> >
> > http://www.informatimago.com/develop/lisp/small-cl-pgms/
> >
> > but it doesn't seem to leverage features than Lisp has and OCaml lacks (i.e.
> > code as data and arbitrary macros) as much as it could.
>
> Try Pseudoscheme: http://mumble.net/~jar/pseudoscheme/
>
> It's not actually an interpreter but rather a compiler, but I think it
> shows well how to embed a different language in Common Lisp.
>
> If it has to be an interpreter, why?
I think there's a difference between Common Lisp and Scheme here.
If you write an interpreter then you're writing a program that can
convert a expression in some other language into a set of function
calls. The function calls being parts of your interpreter that do
things in the language you're creating.
In Scheme the obvious thing to do is to evaluate these function calls
using some kind of evaluator. In CL though, compile is a function like
any other, so by the time you've figured out the function calls you
need you may as well compile the expression I would have thought.
(Maybe there is some gotcha I'm missing here, the only one I can think
of is recursively calling the compiler which you should be able to
avoid).
Rob Thorpe wrote:
>> If it has to be an interpreter, why?
>
> I think there's a difference between Common Lisp and Scheme here.
>
> If you write an interpreter then you're writing a program that can
> convert a expression in some other language into a set of function
> calls. The function calls being parts of your interpreter that do
> things in the language you're creating.
>
> In Scheme the obvious thing to do is to evaluate these function calls
> using some kind of evaluator. In CL though, compile is a function like
> any other, so by the time you've figured out the function calls you
> need you may as well compile the expression I would have thought.
Both SBCL and Scheme48 compile their stuff directly. Scheme48 "only"
uses bytecode on a VM, though.
You don't call the compiler, but everything (including lambdas) gets
compiled to low-level code on the fly.
--
Some people like democracy. That's because it does whatever the
majority wants, and because they happen to be part of that majority.
"Do you want the Total War?"
Ulrich Hobelmann wrote:
> Rob Thorpe wrote:
> >> If it has to be an interpreter, why?
> >
> > I think there's a difference between Common Lisp and Scheme here.
> >
> > If you write an interpreter then you're writing a program that can
> > convert a expression in some other language into a set of function
> > calls. The function calls being parts of your interpreter that do
> > things in the language you're creating.
> >
> > In Scheme the obvious thing to do is to evaluate these function calls
> > using some kind of evaluator. In CL though, compile is a function like
> > any other, so by the time you've figured out the function calls you
> > need you may as well compile the expression I would have thought.
>
> Both SBCL and Scheme48 compile their stuff directly. Scheme48 "only"
> uses bytecode on a VM, though.
>
> You don't call the compiler, but everything (including lambdas) gets
> compiled to low-level code on the fly.
Yes, I was suggesting this approach for implementations that don't do
this, which is most of the rest of them.
"Rob Thorpe" <·············@antenova.com> writes:
> Pascal Costanza wrote:
>> Jon Harrop wrote:
>> > Does anyone know of a suitably simple interpreter written in Lisp (say <
>> > 2kLOC) than I can port to OCaml in order to compare the effort required to
>> > write an interpreter in these languages and the resulting performance?
>> >
>> > I've had a little Google and found this BASIC interpreter:
>> >
>> > http://www.informatimago.com/develop/lisp/small-cl-pgms/
>> >
>> > but it doesn't seem to leverage features than Lisp has and OCaml lacks (i.e.
>> > code as data and arbitrary macros) as much as it could.
>>
>> Try Pseudoscheme: http://mumble.net/~jar/pseudoscheme/
>>
>> It's not actually an interpreter but rather a compiler, but I think it
>> shows well how to embed a different language in Common Lisp.
>>
>> If it has to be an interpreter, why?
>
> I think there's a difference between Common Lisp and Scheme here.
>
> If you write an interpreter then you're writing a program that can
> convert a expression in some other language into a set of function
> calls. The function calls being parts of your interpreter that do
> things in the language you're creating.
>
> In Scheme the obvious thing to do is to evaluate these function calls
> using some kind of evaluator. In CL though, compile is a function like
> any other, so by the time you've figured out the function calls you
> need you may as well compile the expression I would have thought.
>
> (Maybe there is some gotcha I'm missing here, the only one I can think
> of is recursively calling the compiler which you should be able to
> avoid).
I think that's irrelevant, in general.
Let's assume a language where you can define functions taking an
argument, that can return a sum of constant numbers and this argument.
(fonction f1 (x) (+ x x 2))
(fonction f2 (x) (+ x x x x))
Ok, you can interpret or compile this quite directly to CL. This is
because it's actually a semantic subset of CL.
But what if we have for example a statically typed language with
datatypes and operations (pointers, modulo arithmetic, etc) that don't
match directly to lisp, like C. Or a language about colors and
temporal logic. Then you have to implement a kind of virtual machine,
be it as an interpreter or as the target for the code you'll generate
and compile. Then an interpreter cannot just call "native" lisp
functions. The primitives of the interpreter will be the entry points
of a virtual machine emulating the fundamental sematics of the alien
language. "some kind of evaluataor".
--
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Pascal Bourguignon wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
>
> > Pascal Costanza wrote:
> >> Jon Harrop wrote:
> >> > Does anyone know of a suitably simple interpreter written in Lisp (say <
> >> > 2kLOC) than I can port to OCaml in order to compare the effort required to
> >> > write an interpreter in these languages and the resulting performance?
> >> >
> >> > I've had a little Google and found this BASIC interpreter:
> >> >
> >> > http://www.informatimago.com/develop/lisp/small-cl-pgms/
> >> >
> >> > but it doesn't seem to leverage features than Lisp has and OCaml lacks (i.e.
> >> > code as data and arbitrary macros) as much as it could.
> >>
> >> Try Pseudoscheme: http://mumble.net/~jar/pseudoscheme/
> >>
> >> It's not actually an interpreter but rather a compiler, but I think it
> >> shows well how to embed a different language in Common Lisp.
> >>
> >> If it has to be an interpreter, why?
> >
> > I think there's a difference between Common Lisp and Scheme here.
> >
> > If you write an interpreter then you're writing a program that can
> > convert a expression in some other language into a set of function
> > calls. The function calls being parts of your interpreter that do
> > things in the language you're creating.
> >
> > In Scheme the obvious thing to do is to evaluate these function calls
> > using some kind of evaluator. In CL though, compile is a function like
> > any other, so by the time you've figured out the function calls you
> > need you may as well compile the expression I would have thought.
> >
> > (Maybe there is some gotcha I'm missing here, the only one I can think
> > of is recursively calling the compiler which you should be able to
> > avoid).
>
> I think that's irrelevant, in general.
>
> Let's assume a language where you can define functions taking an
> argument, that can return a sum of constant numbers and this argument.
>
> (fonction f1 (x) (+ x x 2))
> (fonction f2 (x) (+ x x x x))
>
> Ok, you can interpret or compile this quite directly to CL. This is
> because it's actually a semantic subset of CL.
>
> But what if we have for example a statically typed language with
> datatypes and operations (pointers, modulo arithmetic, etc) that don't
> match directly to lisp, like C. Or a language about colors and
> temporal logic. Then you have to implement a kind of virtual machine,
> be it as an interpreter or as the target for the code you'll generate
> and compile. Then an interpreter cannot just call "native" lisp
> functions. The primitives of the interpreter will be the entry points
> of a virtual machine emulating the fundamental sematics of the alien
> language. "some kind of evaluataor".
I didn't say that the interpreter could use native lisp functions to
implement the other language. I said that it could use compiled
functions to implement it.
Lets say I was writing an implementation of C in lisp for example.
Many aspects of the C language are completely different to lisp,
pointers are often used for example. But this need not be a real
problem, functions can be written that work with these arguments.
Taking some C:
results.s21w[row] = 0;
This is converted into something like:
(c-set-integer
(c-array-access
(c-struct-access (c-variable-access 'results)
's21w)
'row)))
The "c-" function pass information to each other through some data
structure unseen here. (There may also be global state, but if there
is the tree created must match the execution order of C.)
The "c-" functions are part of the C implementation, the whole
expression above may be compiled. It is even possible to expand some
of the "c-" functions, if that could help.
I'm not saying that the construction of a VM can be avoided, it can't.
But it's not really necessary to use a evaluator in the form of some
recursive/iterative function that passes over an intermediate form.
I'm also not saying that this would be as fast as a proper compiled
language, it wouldn't. It should be better than a recursive
interpreter though.
"Rob Thorpe" <·············@antenova.com> writes:
> I didn't say that the interpreter could use native lisp functions to
> implement the other language. I said that it could use compiled
> functions to implement it.
>
> Lets say I was writing an implementation of C in lisp for example.
> Many aspects of the C language are completely different to lisp,
> pointers are often used for example. But this need not be a real
> problem, functions can be written that work with these arguments.
>
> Taking some C:
> results.s21w[row] = 0;
>
> This is converted into something like:
>
> (c-set-integer
> (c-array-access
> (c-struct-access (c-variable-access 'results)
> 's21w)
> 'row)))
>
> The "c-" function pass information to each other through some data
> structure unseen here. (There may also be global state, but if there
> is the tree created must match the execution order of C.)
>
> The "c-" functions are part of the C implementation, the whole
> expression above may be compiled. It is even possible to expand some
> of the "c-" functions, if that could help.
>
> I'm not saying that the construction of a VM can be avoided, it can't.
> But it's not really necessary to use a evaluator in the form of some
> recursive/iterative function that passes over an intermediate form.
>
> I'm also not saying that this would be as fast as a proper compiled
> language, it wouldn't. It should be better than a recursive
> interpreter though.
Agreed.
--
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Pascal Costanza wrote:
> Try Pseudoscheme: http://mumble.net/~jar/pseudoscheme/
>
> It's not actually an interpreter but rather a compiler, but I think it
> shows well how to embed a different language in Common Lisp.
That's excellent. However, I'd rather the target language was not a close
relative of either Lisp or ML. Scheme is very close to Lisp, so Lisp would
clearly have a huge advantage here.
BASIC would be quite nice but the interpreter that I found doesn't seem to
leverage Lisp's features and I can't get it to run.
> If it has to be an interpreter, why?
Good point. I just want something that can execute programs written in
another language. I don't care how it works internally. I'm not sure what a
more appropriate word than "interpreter" is, but that clearly isn't the
optimal word.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Pascal Costanza wrote:
> > Try Pseudoscheme: http://mumble.net/~jar/pseudoscheme/
> >
> > It's not actually an interpreter but rather a compiler, but I think it
> > shows well how to embed a different language in Common Lisp.
>
[snip]
>
> Good point. I just want something that can execute programs written in
> another language. I don't care how it works internally. I'm not sure what a
> more appropriate word than "interpreter" is, but that clearly isn't the
> optimal word.
Jon, did you miss the key word "embed" in Pascal's description?
Your question seems to be "I'd like to see how to replicate a sow's ear
using silk, while exploiting the advantages silk has to offer?"
The advantage Lisp has in interpreting/compiling/embedding extension
languages is in integrating those languages seamlessly into the Lisp
language. I.e. the user gains the expressiveness of the hosted
language, while retaining all the advantages of Lisp, without the
implementer having to deliver a completely new language implementation.
Your use of the term "interpreter" does not seem to include this
integration aspect.
In any case, you might consider the example of f2cl, translating
Fortran into Common Lisp.
···············@hotmail.com" <············@gmail.com> writes:
> In any case, you might consider the example of f2cl, translating
> Fortran into Common Lisp.
(Note: there have been other Fortran->Lisp translators in the past,
as well as Fortran compilers written in Lisp.)
Christopher C. Stacy wrote:
> ···············@hotmail.com" <············@gmail.com> writes:
>> In any case, you might consider the example of f2cl, translating
>> Fortran into Common Lisp.
>
> (Note: there have been other Fortran->Lisp translators in the past,
> as well as Fortran compilers written in Lisp.)
Is there working source available for a simple one (e.g. <1kLOC)?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Christopher C. Stacy wrote:
> > ···············@hotmail.com" <············@gmail.com> writes:
> >> In any case, you might consider the example of f2cl, translating
> >> Fortran into Common Lisp.
> >
> > (Note: there have been other Fortran->Lisp translators in the past,
> > as well as Fortran compilers written in Lisp.)
>
> Is there working source available for a simple one (e.g. <1kLOC)?
Not for free, but you could certainly attempt to purchase it.
···············@hotmail.com" <············@gmail.com> writes:
> Your question seems to be "I'd like to see how to replicate a sow's ear
> using silk, while exploiting the advantages silk has to offer?"
He's thinking of the ANSI StrawMan spec, I believe.
··············@hotmail.com wrote:
> The advantage Lisp has in interpreting/compiling/embedding extension
> languages is in integrating those languages seamlessly into the Lisp
> language. I.e. the user gains the expressiveness of the hosted
> language, while retaining all the advantages of Lisp, without the
> implementer having to deliver a completely new language implementation.
From previous discussions, the point that interested me the most was Lisp's
code as data functionality. I am used to languages that lack this
functionality, so there is a huge gap between writing a slow interpreter
and writing a fast compiler that is not easy to fill, i.e. it is difficult
to write a language implementation in ML that gives intermediate
performance.
I have heard that Lisp greatly smooths this transition and I'd like to study
this more, as objectively as possible. In particular, I'd like to know how
such an implementation in Lisp (probably embedding the target language)
would compare to an ML implementation in terms of size and speed.
> Your use of the term "interpreter" does not seem to include this
> integration aspect.
Yes. I can't see how that integration would be useful for me so I'm not
particularly interested in it. That isn't to say that other people don't
find it very useful, of course. I just don't have any use for it myself.
> In any case, you might consider the example of f2cl, translating
> Fortran into Common Lisp.
That might be a good example. I'll check it out, thanks.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> I have heard that Lisp greatly smooths this transition and I'd like to study
> this more, as objectively as possible. In particular, I'd like to know how
> such an implementation in Lisp (probably embedding the target language)
> would compare to an ML implementation in terms of size and speed.
Then stop trying to take shortcuts, and just learn the damn language!
Pick "Practical Common Lisp", "Paradigms of Artificial Intelligence
Programming" or "On Lisp", and invest time in learning Lisp until you
have (at least) grasped programming macros. And I mean not
theoretically, but by actually writing your own macros. You won't get it
otherwise!
This will take time, but noone has told you that learning Lisp is easy.
Just using it is. It is a different trade off than for many other
languages: Lisp makes easy things harder in order to make hard things
easier.
You will also find plenty of examples in those books that will give you
the answers that you are looking for. Again, there is no shortcut! We
cannot explain the whole thing here in this newsgroup...
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
>>>>> "PC" == Pascal Costanza <··@p-cos.net> writes:
[good advice elided]
PC> This will take time, but noone has told you that learning Lisp
PC> is easy. Just using it is.
Perhaps this assertion can be justified for people whose first N
languages have been non-lispy. But,
PC> It is a different trade off than
PC> for many other languages: Lisp makes easy things harder in
PC> order to make hard things easier.
Which easy things does lisp make harder? Are you speaking as a lisper
or just employing a pedagogical device of sorts?
cheers,
BM
Bulent Murtezaoglu wrote:
>>>>>>"PC" == Pascal Costanza <··@p-cos.net> writes:
>
> [good advice elided]
> PC> This will take time, but noone has told you that learning Lisp
> PC> is easy. Just using it is.
>
> Perhaps this assertion can be justified for people whose first N
> languages have been non-lispy. But,
Maybe.
> PC> It is a different trade off than
> PC> for many other languages: Lisp makes easy things harder in
> PC> order to make hard things easier.
>
> Which easy things does lisp make harder? Are you speaking as a lisper
> or just employing a pedagogical device of sorts?
No, I don't think so. For example, among the languages I have used
before, Oberon was really nice in that you never needed to think about
setting up make files due to its nice module system. In the end, make
files, or system definitions, are necessary for "serious" programming,
and in Common Lisp you are faced with the need much earlier, I think.
Another example is the complexity of CLOS. In other OO languages you
have much fewer options (like just single inheritance and single
dispatch) which, I think, makes learning such languages simpler because
you don't have to worry about not using features that aren't there in
the first place. However, CLOS enables a programming style using mixins,
or fully generic functions which are in the end more useful.
So essentially, in Common Lisp you are faced much earlier with
constructs that only make life considerably easier in large-program
settings, while a subset of Common Lisp would probably suffice for
simple programs.
This is just a claim, I cannot prove this.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
On Mon, 26 Sep 2005 21:07:49 +0200, Pascal Costanza wrote:
>However, CLOS enables a programming style using mixins,
This is a really basic question, but would it be fair to characterize
a mixin as a java style interface with a default implementation?*
I've seen bits and pieces of mixin code (and in fact have used a mixin to
simulate funcallable objects in CLOSes that don't support them well), but
I am not completely clear on what gets factored into a mixin.
Matt
*which, of course, could be a (partial) abstract class in languages that
support multiple inheritance.
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> On Mon, 26 Sep 2005 21:07:49 +0200, Pascal Costanza wrote:
>
>>However, CLOS enables a programming style using mixins,
>
> This is a really basic question, but would it be fair to characterize
> a mixin as a java style interface with a default implementation?*
Yes, roughly. It's essentially a class that is not supposed to be
instantiated, but rather to be used as an additional superclass
alongside the "primary" superclass. So it's basically a code reuse
mechanism.
> I've seen bits and pieces of mixin code (and in fact have used a mixin to
> simulate funcallable objects in CLOSes that don't support them well), but
> I am not completely clear on what gets factored into a mixin.
It's nice that CLOS doesn't restrict the things you can do with what you
would use as a mixin. There are languages that provide mixins as
separate language constructs and impose different semantics for them as
for regular classes.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza wrote:
> Another example is the complexity of CLOS. In other OO
> languages you have much fewer options (like just single
> inheritance and single dispatch) which, I think, makes
> learning such languages simpler because you don't have to
> worry about not using features that aren't there in the
> first place.
In the late 80's a friend tried to show me Smalltalk. He
typed in a few things, and it looked cool, so I wanted to
have a go. That was nearly 20 years ago, so I don't remember
any Smalltalk, but I do remember what I wanted to do, and in
Common Lisp it would look like this:
(defclass mod7 ()
((n :accessor n
:initarg :n)))
I imagined that a simple example of an object would be a
number modulo 7. The object has internal state, the value of
the number, but it is /internal/, its objectness gives it a
distinctive meaning.
If I just press on with code in CL you will soon see what I
was trying to do
(defclass mod12 ()
((n :accessor n
:initarg :n)))
(defvar 5mod7 (make-instance 'mod7 :n 5))
(defvar 6mod7 (make-instance 'mod7 :n 6))
(defvar 5mod12 (make-instance 'mod12 :n 5))
(defvar 6mod12 (make-instance 'mod12 :n 6))
(defmethod add ((x mod7)(y mod7))
(make-instance 'mod7 :n (mod (+ (n x)
(n y))
7)))
(defmethod add ((x mod12)(y mod12))
(make-instance 'mod12 :n (mod (+ (n x)
(n y))
12)))
(describe (add 5mod7 6mod7))
#<MOD7 {480E9315}> is an instance of class #<Standard-Class MOD7 {480862FD}>:
The following slots have :INSTANCE allocation:
N 4
(describe (add 5mod12 6mod12))
#<MOD12 {480FA8ED}> is an instance of class #<Standard-Class MOD12 {480975D5}>:
The following slots have :INSTANCE allocation:
N 11
It is a very simple idea: 5+6=4 mod 7 but 5+6=11 mod 12.
It was the simplest example I could think of to try out
object oriented programming. I wanted to try out having a
function do different things to objects of different kinds,
so I needed two kinds of objects, integers modulo 7 and
integers modulo twelve, and a function, addition, that could
plausibly behave differently on the two different kinds of
objects.
I'm not sure at what age children are taught arithmetic
modulo n. Arithmetic modulo 10 (ie 5+6 is one unit and one
ten) must be young (8? 9?).
I thought my example was childlike in its simplicity. I was
thunderstruck when there turned out to be a technical
difficulty with doing this in Smalltalk.
I thought that the differentness of the classes, with mod7
being different from mod12, was an inherent property of the
classes, yet somehow it seemed to be a relative property,
dependent on the object's position in the argument list,
visible if the object was the first argument, yet invisible
if the object was the second argument.
I found this incomprehensibly awful. It completely destroyed
the object metaphor. Nothing that I was familiar with
behaved like this. It was as though I had a bowl of apples
and oranges and I could pick up any single fruit and it would
stay an apple or an orange, but when I picked up a second
one its distinctive appleness or orangeness would vanish and
I would only have a generic fruit in my hand.
When I'm writing code I don't merely anthropomorphize my
functions, I decenter and become them.
(defun foo (n)
(cond ((evenp n) ...
NOT "foo checks whether n is even ...", BUT "First /I/ check
whether n is even ...".
So being unable to see whether my second argument was mod7
or mod12 felt like losing an eye. I fled in horror from this
hideous, mutilating language. The trauma of my first
encounter with single dispatch remains vivid in my memory
nearly twenty years later, the sub-basement in St Stephen's
Street, the grey light from the two windows behind me,...
I often see attempts to justify single dispatch by a concern
for human factors, claiming that it is easy to learn and simple to
understand. My exerience could not be more different.
Alan Crowe
Edinburgh
Scotland
Stefan Ram wrote:
In this special case, dispatching on the type of the first
argument would behave similar, because this type always seems
to be equal to the type of the second argument, i.e., in Java:
mod7number0.add( mod7number1 );
mod9number0.add( mod9number1 );
So another example might be suited better, where dispatching
on the type of the first argument alone will not yield the
same results.
Well, another example might make the point more strongly,
but it would not be faithful to the actual event. I would
rather tell more of the true story.
I was doing the mod7 and mod12 as a warm up exercise. I
never imagined that anything would go wrong. I was thinking
ahead, first a simple exercise to get familiar with the
syntax, then I could go on to do a vector space, with scalar
times vector, or my objects might be tensors. It would be
nice to do some kind of summation convention, so that there
would only be one kind of product, and it would pick up
which indices to contract by which were repeated. Would
Smalltalk make that easy or hard?
Then I came down to earth with a bump. The trivial warm up
exercise wasn't going as I expected. I couldn't just type it
in, fix the typos, watch in go, and press on to the next
step. There was a problem right at the start, a problem that
made not the slightest sense to me. How could the
fashionable new thing fail on the warm up exercise before I
got on to trying it out? It was the shock of it that fixed
it in my memory. Imagine that you are all hyped up to play
in the big match at the indoor stadium, but the match is
called off because it rained and the pitch got
waterlogged. It was that kind of shock.
Hmm. That is not as precise a metaphor as it should be. My
sense of shock centered on the way that the flashy new
feature only worked on one of the arguments instead of on
all of them.
Imagine it is 1720 and you drop in on Cristofori's workshop
to see the new fortepiano that is causing uproar in the
world of keyboard music. It is a great leap forward,
compared to the harpsichord, because the notes are touch
sensitive. Press hard for a loud sound, press softly for a
quiet sound.
You try it out. Only one note is touch sensitive, all the
others play at a fixed volume.....
Such a thing is inconceivable. If it really happened, the
weirdness of it would haunt you for the rest of your days.
Alan Crowe
Edinburgh
Scotland
Alan,
> Hmm. That is not as precise a metaphor as it should be. My
> sense of shock centered on the way that the flashy new
> feature only worked on one of the arguments instead of on
> all of them.
That is a feature of object oriented programming as defined by Alan Kay
when he created the term: each object is like a little self contained
computer exchanging messages with the others over some network.
Having multiple dispatch makes your example possible without having to
do an ugly double dispatching pattern but it does dilute object
orientedness by moving the generic functions outside of the objects. It
is a matter of taste whether this small loss is worth the gains or not.
See http://slate.tunes.org/ for a very nice Smalltalkish language with
multiple dispatch. It originally ran on top of Common Lisp but now is a
stand alone system (already usable but with a lot of development
ahead).
-- Jecel
Jecel wrote:
> Alan,
>
>
>>Hmm. That is not as precise a metaphor as it should be. My
>>sense of shock centered on the way that the flashy new
>>feature only worked on one of the arguments instead of on
>>all of them.
>
>
> That is a feature of object oriented programming as defined by Alan Kay
> when he created the term: each object is like a little self contained
> computer exchanging messages with the others over some network.
>
> Having multiple dispatch makes your example possible without having to
> do an ugly double dispatching pattern but it does dilute object
> orientedness by moving the generic functions outside of the objects. It
> is a matter of taste whether this small loss is worth the gains or not.
This isn't exactly true. If you go objects all the way down, everybody
gets a message, and every parameter in your function gets to figure out
what its behavior should be. This is more than a bit troublesome to
implement efficiently, but it's (more or less) the way that Kay et al
first defined Smalltalk. Single dispatch is much simpler both
conceptually and mechanically, which is why it became the thing when the
PARC folks wanted a language they could do substantial amounts of work in.
paul
Jecel wrote:
> Alan,
>
>
>>Hmm. That is not as precise a metaphor as it should be. My
>>sense of shock centered on the way that the flashy new
>>feature only worked on one of the arguments instead of on
>>all of them.
>
>
> That is a feature of object oriented programming as defined by Alan Kay
> when he created the term: each object is like a little self contained
> computer exchanging messages with the others over some network.
>
> Having multiple dispatch makes your example possible without having to
> do an ugly double dispatching pattern but it does dilute object
> orientedness by moving the generic functions outside of the objects. It
> is a matter of taste whether this small loss is worth the gains or not.
Brian Foote has implemented multiple dispatch for Smalltalk without
breaking the notion that a method belongs to a class. This isn't very
interesting if you have CLOS, but it may be interesting for
Smalltalkers. You can read about it in a paper he presented at this
year's ECOOP. (It's a nice read - he also acknowledges CLOS a lot in there.)
See http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Thankyou for the note about the history.
When Jecel writes
> Having multiple dispatch makes your example possible
> without having to do an ugly double dispatching pattern
> but it does dilute object orientedness by moving the
> generic functions outside of the objects.
I have to disagree on both counts. Does multiple dispatch
dilute object orientedness and does moving the generic functions
outside of the objects do so?
Consider
(defclass a()())
(defclass b()())
(defclass c()())
If we don't use an object oriented function call mechanism
we have to write something like
(defun f (x)
(typecase x
(a ...)
(b ...)
(c ...)))
The substantial issue is that we might very well have the
class definitions in separate files, or otherwise
distributed about the program souce, and so we face a
problem with where the definition of f should go.
Defmethod lets us write
(defmethod f ((x a))...)
(defmethod f ((x b))...)
(defmethod f ((x c))...)
and the seperate method definitions can be grouped with the
class definitions, going in the relevant file if that is how
we have chosen to organise our code.
So the generic functions have only moved outside of the
objects in a trivial, formal sense based on where exactly
the brackets go, the code is still well organised, with the
methods definitions grouped each with his own class.
We face a problem with where to put
(defmethod f ((x a)(y b))...)
but we also face a problem with where to put
(defmethod f ((x a)(thing t))
(typecase thing
(a ...)
(b ...)
(c ...)))
and this latter problem is as hard or harder.
Leaving the particular mechanism of dilution, I turn to
whether dilution is a helpful concept here.
I've been Googling on "multiple dispatch versus single
dispatch" and "message passing versus generic functions" to
read around the topic. I'm mostly finding
superficiallity. One post caught my eye. A generic function
for a drum sound dispatched both on the type of the drum and
the type of the drum stick. Both the drum and the stick have
equal legitimacy as objects. It strikes me that squeezing
this into a message passing framework does indeed dilute
object orientedness by demoted some objects to tagged unions
to be fed into dispatch code in the old fashioned way.
This was one of the points I tried to make earlier and I
think I made it quite vividly. So it is painful to read
Having multiple dispatch makes your example possible
without having to do an ugly double dispatching pattern
but it does dilute object orientedness ...
^^^^^^^^^^^^^^^^^^^^^^^^^^
My point was, in part, that one wants to grant an object its
"type dispatch rights" even if it is not in first position,
least one dilute object orientedness. So the common desire
to preserve object orientedness at full strength makes us
argue opposite positions.
Perhaps dilution is too vague a metaphor. Maybe one needs
more focused concerns such as whether
1)Object orientedness pervades the syntax or is only present
in selected places
2)Code specific to a single object can be grouped with that
object's class definition
Alan Crowe
Edinburgh
Scotland
Alan Crowe wrote:
> My point was, in part, that one wants to grant an object its
> "type dispatch rights" even if it is not in first position,
> least one dilute object orientedness. So the common desire
> to preserve object orientedness at full strength makes us
> argue opposite positions.
The problem is that we have very different definitions for "object
oriented". That is normal, since people have redefined the term many
times since Alan Kay invented it so unfortunately it is becoming as
useless as "hacker", for example.
If you read "The Early History of Smalltalk" by Alan Kay you will see
that the language was originally supposed to be a pattern matching
extension of Logo and so it would have had multiple dispatch. This
paper design is called Smalltalk-71 in that paper. The idea that it was
acceptable, and even desirable to have "3+4" not give both 3 and 4
equal status took a while to develop.
So in my definition of "object oriented" you have to look at where the
mechanism for handling incoming messages lives, and for single dispatch
it is inside the objects themselves (though an actual implementation
won't normally do it this way) while for multiple dispatch, as in your
example, it is some third party other than any of the arguments.
Alan Kay's background includes molecular biology so he thought about
self contained cells and about membranes for encapsulation. My
background is hardware so I think in terms of replacing a software
object with an equivalent chip.
Please note that I am not saying one definition of "object oriented" is
more valid than the other, just that they are different so that if
Smalltalk doesn't match yours it isn't fair to say its claim is wrong.
-- Jecel
Jecel wrote
> The idea that it was acceptable, and even desirable to
> have "3+4" not give both 3 and 4 equal status took a while
> to develop.
As a tired, old cynic it is easy for me to imagine that the
Small talk group was finding it difficult to implement
multiple dispatch efficiently, and the desirability of
single dispatch was a rationalisation that they welcomed
because it solved a hard problem.
On the other hand there are senses in which coding
mathematics is the easiest kind of coding. Maybe "3+4" is
misleading because "+" is in there jostling for recognition
as an object that combines two object. Maybe Alan Kay tried
to get beyond that and had a clever insight into other
computations.
So perhaps, when I dismiss single dispatch, it is me who
loses out.
On the third hand :-) category theory has objects and
morphism, and one often makes an "upper" category whose
objects are the morphisms of a "lower" category so maybe the
pattern in "3+4" of an object that joins other objects is
the basic pattern of the world and single dispatch is an
error.
So when I go goggling for "single dispatch versus multiple
dispatch" and "message passing versus generic functions" I'm
hoping to come across a cool idea and say "Ah, now I see what
Kay was on about."
> Alan Kay's background includes molecular biology so he
> thought about self contained cells and about membranes for
> encapsulation. My background is hardware so I think in
> terms of replacing a software object with an equivalent
> chip.
Cells combine to form multicellular organisms and most
circuits contain several chips working together. On the
other hand there are a lot of messages passing to and
fro. So it is tempting to respond with a metaphor in which
there are aggregators, objects and things. Objects send each
other things as messages, (single dispatch). Objects can
arise from aggregators grouping sub-objects (multiple
dispatch)... I've no idea where I'm going with this.
Alan Crowe
Edinburgh
Scotland
On 29 Sep 2005 18:13:23 GMT, ···@zedat.fu-berlin.de (Stefan Ram)
wrote:
> Messages are not actually sent to /objects/ in object-oriented
> languages, because then, there would be no polymorphism,
> because a specific object always has a specific class (type).
>
> Instead, messages are send to expressions. The value of this
> receiving expression (the object) is determined at runtime.
> So, this is late-binding or runtime polymorphism.
When people talk about sending messages to objects, they
are talking about what happens in a running program.
In source code there is a syntax for sending a message
to the object that is the value of an expression at run time,
and people loosely talk about such source code as "sending a
message".
Simon
___________________
Real email address:
(substitute ··@ #\+ (substitute #\s #\! "u!enet001+nomi!tech.com"))
On 29 Sep 2005 18:13:23 GMT, ···@zedat.fu-berlin.de (Stefan Ram)
wrote:
> As the (English) language indicates a "receiver" of a message
> can only be a single entity. As I wrote before, in the case of
> multi-methods, this has to be a tuple. E.g., in "2+3" the
> message "+" is sent to the pair "(2,3)" of the type "int x
> int", this pair is a single object.
I mean to say in my earlier message:
The metaphor of messages breaks down with multimethods.
___________________
Real email address:
(substitute ··@ #\+ (substitute #\s #\! "u!enet001+nomi!tech.com"))
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Jecel wrote
>> The idea that it was acceptable, and even desirable to
>> have "3+4" not give both 3 and 4 equal status took a while
>> to develop.
>
> As a tired, old cynic it is easy for me to imagine that the
> Small talk group was finding it difficult to implement
> multiple dispatch efficiently, and the desirability of
> single dispatch was a rationalisation that they welcomed
> because it solved a hard problem.
>
> On the other hand there are senses in which coding
> mathematics is the easiest kind of coding. Maybe "3+4" is
> misleading because "+" is in there jostling for recognition
> as an object that combines two object. Maybe Alan Kay tried
> to get beyond that and had a clever insight into other
> computations.
Or perhaps they got it reversed:
+ operate: 3 and: 4
+ operate: ( * operate: 2 and: 3 ) and: 4
but we already have it in lisp (+ 3 4), (+ (* 2 3) 4).
> So perhaps, when I dismiss single dispatch, it is me who
> loses out.
>
> On the third hand :-) category theory has objects and
> morphism, and one often makes an "upper" category whose
> objects are the morphisms of a "lower" category so maybe the
> pattern in "3+4" of an object that joins other objects is
> the basic pattern of the world and single dispatch is an
> error.
Of course, that's why you must write + 3 4, not 3 + 4 !
> [...]
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
Pascal Costanza wrote:
> Jon Harrop wrote:
>> I have heard that Lisp greatly smooths this transition and I'd like to
>> study this more, as objectively as possible. In particular, I'd like to
>> know how such an implementation in Lisp (probably embedding the target
>> language) would compare to an ML implementation in terms of size and
>> speed.
>
> Then stop trying to take shortcuts, and just learn the damn language!
> Pick "Practical Common Lisp", "Paradigms of Artificial Intelligence
> Programming" or "On Lisp", and invest time in learning Lisp until you
> have (at least) grasped programming macros. And I mean not
> theoretically, but by actually writing your own macros. You won't get it
> otherwise!
In point of fact, I spent most of the weekend trying to write my ray tracer
in Lisp. Even with Nathan and Juho's working Lisp implementations as
templates I have failed to get a working version.
For about 6 hours, I just got type error after type error. Only, rather than
getting them at compile time, I got them randomly about 5 mins into run
time (or not at all if I choose a small problem). Once I'd gotten rid of
the type errors the program ran but produced the wrong output. Now I've
"fixed it", I'm back to more run-time type errors...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> For about 6 hours, I just got type error after type error. Only, rather than
> getting them at compile time, I got them randomly about 5 mins into run
> time (or not at all if I choose a small problem). Once I'd gotten rid of
> the type errors the program ran but produced the wrong output. Now I've
> "fixed it", I'm back to more run-time type errors...
>
You are not using the REPL properly. Unit test the functions in the
REPL, make sure they are right before moving forward. It sounds like
you are coding the whole thing before testing anything, that is not the
Lisp way.
Wade
Wade Humeniuk wrote:
> You are not using the REPL properly. Unit test the functions in the
> REPL, make sure they are right before moving forward. It sounds like
> you are coding the whole thing before testing anything, that is not the
> Lisp way.
I am using the REPL and I am testing each function in turn. Often my unit
tests don't turn up type errors but real-use does. Lots and lots of simple
type errors...
I'm currently having problems with a "fold" that I've defined. I think I
need to put #' before the name of the function argument, but I've no idea
why. :-(
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Tue, 27 Sep 2005 03:09:55 +0100, Jon Harrop wrote:
> Wade Humeniuk wrote:
>> You are not using the REPL properly. Unit test the functions in the
>> REPL, make sure they are right before moving forward. It sounds like
>> you are coding the whole thing before testing anything, that is not the
>> Lisp way.
>
> I am using the REPL and I am testing each function in turn. Often my unit
> tests don't turn up type errors but real-use does. Lots and lots of simple
> type errors...
>
> I'm currently having problems with a "fold" that I've defined. I think I
> need to put #' before the name of the function argument, but I've no idea
> why. :-(
Your experience, and this thread remind me of this erlang thread:
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/threads.html#02779
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> On Tue, 27 Sep 2005 03:09:55 +0100, Jon Harrop wrote:
>> I'm currently having problems with a "fold" that I've defined. I think I
>> need to put #' before the name of the function argument, but I've no idea
>> why. :-(
I just went back to it with a fresh head and fixed all of the type errors.
Turns out I'd put a brace in the wrong place so "intersect" was returning
NIL. So it works, but it still doesn't fit on the performance graph. ;-)
> Your experience, and this thread remind me of this erlang thread:
>
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/threads.html#02779
I think its a great shame that people base their views of static typing on
Java, C++ or even C. I mean, Hindley-Milner is over 30 years old now and is
the basis for the static typing in lots of different languages. They could
at least bother to read up on that. I'm not even a computer scientist and
I've read up on it...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Tue, 27 Sep 2005 04:40:00 +0100, Jon Harrop wrote:
> I think its a great shame that people base their views of static typing on
> Java, C++ or even C. I mean, Hindley-Milner is over 30 years old now and is
> the basis for the static typing in lots of different languages. They could
> at least bother to read up on that. I'm not even a computer scientist and
> I've read up on it...
Yes, there is that, but the thread also touches on the more subjective
qualities that make developers prefer one type discipline over another.
If you're in the kind of mind set that ordinarily makes you a productive
ML programmer, programming in Lisp will be intolerable (and vice versa).
Matt
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Matthew D Swank wrote:
> Yes, there is that, but the thread also touches on the more subjective
> qualities that make developers prefer one type discipline over another.
> If you're in the kind of mind set that ordinarily makes you a productive
> ML programmer, programming in Lisp will be intolerable (and vice versa).
Interesting. Of people that I know IRL, the ML programmers and Lisp
programmers are disjoint sets. However, I only know (of) one Lisp
programmer. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
On Tue, 27 Sep 2005 04:40:00 +0100, Jon Harrop <······@jdh30.plus.com> wrote:
>> On Tue, 27 Sep 2005 03:09:55 +0100, Jon Harrop wrote:
>>> I'm currently having problems with a "fold" that I've defined. I
>>> think I need to put #' before the name of the function argument,
>>> but I've no idea why. :-(
>
> [snip]
>
> I think its a great shame that people base their views of static
> typing on Java, C++ or even C. I mean, Hindley-Milner is over 30
> years old now and is the basis for the static typing in lots of
> different languages. They could at least bother to read up on that.
I think it's a great shame that people base their views of Lisp on a
few hours of experience. They could at least bother to learn it
properly before they start educating other people.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Jon Harrop wrote:
> Matthew D Swank wrote:
>
>>On Tue, 27 Sep 2005 03:09:55 +0100, Jon Harrop wrote:
>>
>>>I'm currently having problems with a "fold" that I've defined. I think I
>>>need to put #' before the name of the function argument, but I've no idea
>>>why. :-(
>
>
> I just went back to it with a fresh head and fixed all of the type errors.
> Turns out I'd put a brace in the wrong place so "intersect" was returning
> NIL. So it works, but it still doesn't fit on the performance graph. ;-)
>
>
>>Your experience, and this thread remind me of this erlang thread:
>>
>
> http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/threads.html#02779
>
> I think its a great shame that people base their views of static typing on
> Java, C++ or even C. I mean, Hindley-Milner is over 30 years old now and is
> the basis for the static typing in lots of different languages. They could
> at least bother to read up on that. I'm not even a computer scientist and
> I've read up on it...
>
Hindley-Milner is a great idea that gets in the way of programmers.
Placating a type-checker in ML et similia is a about as much work as
fixing things on the fly in CL. Only programming in CL is much more fun :)
Cheers
--
Marco
Jon Harrop wrote:
> Wade Humeniuk wrote:
>
>>You are not using the REPL properly. Unit test the functions in the
>>REPL, make sure they are right before moving forward. It sounds like
>>you are coding the whole thing before testing anything, that is not the
>>Lisp way.
>
> I am using the REPL and I am testing each function in turn. Often my unit
> tests don't turn up type errors but real-use does. Lots and lots of simple
> type errors...
>
> I'm currently having problems with a "fold" that I've defined. I think I
> need to put #' before the name of the function argument, but I've no idea
> why. :-(
Don't expect any sympathy. You are not trying to learn the language, but
you are trying to use it blindly.
"I'm currently having problems with parking in. I think I need to turn
the steering wheel, but I've no idea why. :-("
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza wrote:
>> I'm currently having problems with a "fold" that I've defined. I think I
>> need to put #' before the name of the function argument, but I've no idea
>> why. :-(
>
> Don't expect any sympathy. You are not trying to learn the language, but
> you are trying to use it blindly.
Well, I've never come across a language where you can't just refer to a
function by name but you have to prefix it with "funcall", "function", "#'"
or whatever. From someone else's post, I get the impression that the reason
for having to do this in Lisp is a complicated interaction with run-time
code generation. So I'm postponing studying it in more detail. Do you think
I should study it now?
> "I'm currently having problems with parking in. I think I need to turn
> the steering wheel, but I've no idea why. :-("
c.l.l is analogy central. :-)
PS: Did you get my e-mail about your paper?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Pascal Costanza wrote:
>>> I'm currently having problems with a "fold" that I've defined. I think I
>>> need to put #' before the name of the function argument, but I've no idea
>>> why. :-(
>>
>> Don't expect any sympathy. You are not trying to learn the language, but
>> you are trying to use it blindly.
>
> Well, I've never come across a language where you can't just refer to a
> function by name but you have to prefix it with "funcall", "function", "#'"
> or whatever.
And neither have you come across such a language or, I should say,
at least Common Lisp is not such a language. Common Lisp does what
you ask it to do. You may easily refer to a function by name:
(defun foo (x) ...)
...
(foo 10)
or
(funcall 'foo 10)
or you may refer to it by _value_:
(setq z #'foo)
...
(funcall z 10)
or
(funcall #'foo 10)
But in order to do this, you must learn how to ask Common Lisp what
you want it to do. In your many postings here, you have not given
any of us the impression that you have done this yet.
Another article on another thread in this newsgroup reminds us not
to attribute to trolling as something that can be attributed to
stupidity or ignorance. Since my perception of you through your
postings leads me to believe that you're not stupid, I can only
conclude that you are only still ignorant. People on c.l.l tend
to be willing to help you to overcome your ignorance if you are
willing to admit such ignorannce, but until recently you have
presented your comments from a position of knowledge, rather than
asking questions. Now that you are asking questions, it is much
easier to make the decision to help you, but not when you make
such inflammatory statements like the one you made above. If
you limit your questions to the style you've asked the one below
(still rhetorical, but at least there's a question mark at the end)
then you'd find a great number more people on this n.g. who are
willing to help.
From someone else's post, I get the impression that the reason
> for having to do this in Lisp is a complicated interaction with run-time
> code generation. So I'm postponing studying it in more detail. Do you think
> I should study it now?
Yes. Particularly, you should come to an understanding about the
difference between a function name and a function. No complication
here, just a difference between evaluating a value and calling a
function.
>> "I'm currently having problems with parking in. I think I need to turn
>> the steering wheel, but I've no idea why. :-("
>
> c.l.l is analogy central. :-)
Some tend to resort to analogy when the message doesn't get through any
other way.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> (funcall 'foo 10)
...
> (funcall #'foo 10)
So these expressions obtain the same result by slightly different means. The
former passes the function name "foo" (as quoted code) to "funcall" which
then looks up the function and evaluates it. The latter looks up the
function value and passes that to "funcall" instead. Is that right?
>> From someone else's post, I get the impression that the reason
>> for having to do this in Lisp is a complicated interaction with run-time
>> code generation. So I'm postponing studying it in more detail. Do you
>> think I should study it now?
>
> Yes. Particularly, you should come to an understanding about the
> difference between a function name and a function. No complication
> here, just a difference between evaluating a value and calling a
> function.
So languages that lack code-as-data have no notion of "function name", i.e.
you can't pass a function's name around, only the function value?
Is it possible to use a higher-order "fold" function without using QUOTE?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Duane Rettig wrote:
>> (funcall 'foo 10)
> ...
>> (funcall #'foo 10)
>
> So these expressions obtain the same result by slightly different means. The
> former passes the function name "foo" (as quoted code) to "funcall" which
> then looks up the function and evaluates it. The latter looks up the
> function value and passes that to "funcall" instead. Is that right?
Almost. You can think of 'foo as a symbol, and #'foo as a function object.
In CL, if 'foo is not lexically bound, #'foo is eqivalent to the result of
(symbol-function 'foo). In other words, symbol-name is an accessor on a
symbol which retrieves the function object. When funcall receives either a
symbol or a function object, it does what it necessary to retrieve the
function object, and then invokes it. When it sees a symbol, it retrieves
the symbol's function slot (still assuming the name is not lexically bound
to a different function). If the object passed to funcall is itself a
function object, then funcall already has what it needs, and simply invokes
that.
The reason I pick nits here is that there is still some misunderstanding
about the idea of "looking up" a function's value; whether #'foo is globally
defined or lexically defined in a labels or flet form, the value of #'foo
is immediately available; there is no lookup involved (unless you are
considering the retrieving of the value of a variable to be a "lookup".
Perhaps it is hard to think about, but function objects in CL are truly
first class objects. In whatever lisp you are working with, try defining
a function and then inspecting the name and function object of that
function. Compare the two, as to how they present themselves, and note
how the 'foo symbol points to the #'foo function object - in some lisps the
function object points back toward the symbol it was originally defined
with. It is one of those two objects that gets passed into funcall.
>>> From someone else's post, I get the impression that the reason
>>> for having to do this in Lisp is a complicated interaction with run-time
>>> code generation. So I'm postponing studying it in more detail. Do you
>>> think I should study it now?
>>
>> Yes. Particularly, you should come to an understanding about the
>> difference between a function name and a function. No complication
>> here, just a difference between evaluating a value and calling a
>> function.
>
> So languages that lack code-as-data have no notion of "function name", i.e.
> you can't pass a function's name around, only the function value?
Well, sort of. As someone else pointed out before, C has a concept of
foo and &foo, where &foo is the _address_ of the function foo. In a
language that deals only in addresses like C, I guess you could call &foo
foo's "name" - and in fact you can pass &foo around and call it.
> Is it possible to use a higher-order "fold" function without using QUOTE?
I'm not sure what you're looking for here - why without using QUOTE?
What does QUOTE have to do with this distinction between function name
and function?
If you provide a small example of what you're actually attempting, perhaps
we can help you with it.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
In article <·············@franz.com>, Duane Rettig <·····@franz.com>
wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>
> > Duane Rettig wrote:
> >> (funcall 'foo 10)
> > ...
> >> (funcall #'foo 10)
> >
> > So these expressions obtain the same result by slightly different means. The
> > former passes the function name "foo" (as quoted code) to "funcall" which
> > then looks up the function and evaluates it. The latter looks up the
> > function value and passes that to "funcall" instead. Is that right?
>
> Almost. You can think of 'foo as a symbol, and #'foo as a function object.
> In CL, if 'foo is not lexically bound, #'foo is eqivalent to the result of
> (symbol-function 'foo). In other words, symbol-name is an accessor on a
^^^^^^^^^^^
> symbol which retrieves the function object.
That should be symbol-function of course.
rg
Jon Harrop wrote:
> Pascal Costanza wrote:
>
>>>I'm currently having problems with a "fold" that I've defined. I think I
>>>need to put #' before the name of the function argument, but I've no idea
>>>why. :-(
>>
>>Don't expect any sympathy. You are not trying to learn the language, but
>>you are trying to use it blindly.
>
> Well, I've never come across a language where you can't just refer to a
> function by name but you have to prefix it with "funcall", "function", "#'"
> or whatever. From someone else's post, I get the impression that the reason
> for having to do this in Lisp is a complicated interaction with run-time
> code generation. So I'm postponing studying it in more detail. Do you think
> I should study it now?
As I said before, pick "Practical Common Lisp", "Paradigms of Artificial
Intelligence Programming", "Successful Lisp", or some other good
tutorial on Common Lisp and learn the language from the ground up. It's
all very well explained there. The various features in Common Lisp
support each other, you don't get very far by poking around.
I could refer you to previous discussions about Lisp-1 vs. Lisp-2, but
this will probably distract you from the important thing again, which is
that you need to learn a language in order to be able to use it. Which
is, btw, true of any language and shouldn't surprise you.
Common Lisp is not designed to be easy to learn by novices. If you want
to assess its merits, you either have to make a serious effort to use it
to solve a considerably complex problem, or you have to trust what
experienced Lispers say. The latter is suboptimal, but probably better
than jumping to conclusions from a very superficial look at it.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza wrote:
> As I said before, pick "Practical Common Lisp", "Paradigms of Artificial
> Intelligence Programming", "Successful Lisp", or some other good
> tutorial on Common Lisp and learn the language from the ground up. It's
> all very well explained there.
I've read a decent chunk of PCL now. It certainly explains what you have to
do very well but it doesn't seem to explain why you have to do it, at least
in most cases.
> The various features in Common Lisp support each other, you don't get very
> far by poking around.
Well, after 2.5 days work I managed to get a working ray tracer. :-)
> I could refer you to previous discussions about Lisp-1 vs. Lisp-2, but
> this will probably distract you from the important thing again, which is
> that you need to learn a language in order to be able to use it. Which
> is, btw, true of any language and shouldn't surprise you.
>
> Common Lisp is not designed to be easy to learn by novices. If you want
> to assess its merits, you either have to make a serious effort to use it
> to solve a considerably complex problem, or you have to trust what
> experienced Lispers say. The latter is suboptimal, but probably better
> than jumping to conclusions from a very superficial look at it.
Yes, that makes sense. I'll keep hacking away in my spare time...
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Pascal Costanza wrote:
>>> I'm currently having problems with a "fold" that I've defined. I think I
>>> need to put #' before the name of the function argument, but I've no idea
>>> why. :-(
>>
>> Don't expect any sympathy. You are not trying to learn the language, but
>> you are trying to use it blindly.
>
> Well, I've never come across a language where you can't just refer to a
> function by name but you have to prefix it with "funcall", "function", "#'"
> or whatever. From someone else's post,
Then you don't know C, where functions must be prefixed by &:
#include <math.h>
typedef double(*fun)(double);
fun f = &sin;
int main(void){
printf("%f\n",f(1.0));
return(0);}
> I get the impression that the reason
> for having to do this in Lisp is a complicated interaction with run-time
> code generation. So I'm postponing studying it in more detail. Do you think
> I should study it now?
Look pal, you sound like a smart guy, with all this consulting and camml
behind you. Why do you play dumb here? Just go to
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
and start reading!
--
__Pascal Bourguignon__ http://www.informatimago.com/
The rule for today:
Touch my tail, I shred your hand.
New rule tomorrow.
Pascal Bourguignon wrote:
> Then you don't know C, where functions must be prefixed by &:
>
> #include <math.h>
> typedef double(*fun)(double);
> fun f = &sin;
> int main(void){
> printf("%f\n",f(1.0));
> return(0);}
Very true - should have said "functional language". Did Lisp always have
closures?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
>
> Very true - should have said "functional language". Did Lisp always have
> closures?
No. And I think they evolved incrementally. I recall encountering the
terms "Downward FunArg Problem" and "Upward FunArg Problem" to describe
the two situations. The downward problem was an easier one to solve, so
it ended up being implemented first. That is because the lexical scope
still exists when the downward function is invoked, but it has exited
in the upward case.
The direction refered to the direction in which the function argument
(FunArg) was passed.
Examples:
Downward:
(defun invoker (f x)
(funcall f x))
(defun caller ()
(let ((x 10))
(invoker (lambda (y) (* x y)) 3)))
Upward:
(defun invoker ()
(funcall (maker) 3))
(defun maker ()
(let ((x -10))
(lambda (y) (* x y))))
--
Thomas A. Russ, USC/Information Sciences Institute
Thomas A. Russ wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>>
>> Very true - should have said "functional language". Did Lisp always have
>> closures?
>
> No. And I think they evolved incrementally.
Interesting...
> The direction refered to the direction in which the function argument
> (FunArg) was passed.
There was an enormous thread partly about this on c.l.functional a few
months ago. An Ada programmer was advocating the prohibition of upward
closures. :-)
So, can I now handle closures in Lisp just as I would in any other FPL, i.e.
downwards and upwards?
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Thomas A. Russ wrote:
>
>>Jon Harrop <······@jdh30.plus.com> writes:
>>
>>>Very true - should have said "functional language". Did Lisp always have
>>>closures?
>>
>>No. And I think they evolved incrementally.
>
>
> Interesting...
>
>
>>The direction refered to the direction in which the function argument
>>(FunArg) was passed.
>
>
> There was an enormous thread partly about this on c.l.functional a few
> months ago. An Ada programmer was advocating the prohibition of upward
> closures. :-)
>
> So, can I now handle closures in Lisp just as I would in any other FPL, i.e.
> downwards and upwards?
>
As we say in Italy, "dopo sette fette..." :)
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Jon Harrop wrote:
>> Thomas A. Russ wrote:
>>
>>>Jon Harrop <······@jdh30.plus.com> writes:
>>>
>>>>Very true - should have said "functional language". Did Lisp always have
>>>>closures?
>>>
>>>No. And I think they evolved incrementally.
>> Interesting...
>>
>>>The direction refered to the direction in which the function argument
>>>(FunArg) was passed.
>> There was an enormous thread partly about this on c.l.functional a
>> few
>> months ago. An Ada programmer was advocating the prohibition of upward
>> closures. :-)
>> So, can I now handle closures in Lisp just as I would in any other
>> FPL, i.e.
>> downwards and upwards?
>>
>
> As we say in Italy, "dopo sette fette..." :)
Okay, so Babelfish renders that as "After seven slices". Anyone care
to provide a more idiomatic translation? (I'm guessing it's something
like: "Took you seven tries but you finally got it.")
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Jon Harrop <······@jdh30.plus.com> writes:
> So, can I now handle closures in Lisp just as I would in any other FPL, i.e.
> downwards and upwards?
Read the CLHS!
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
Jon Harrop wrote:
> There was an enormous thread partly about this on c.l.functional a few
> months ago. An Ada programmer was advocating the prohibition of upward
> closures. :-)
Ada people don't like OO?
> So, can I now handle closures in Lisp just as I would in any other FPL, i.e.
> downwards and upwards?
Aren't they first-class values?
--
Do or do not. There is no try.
Yoda
Jon Harrop <······@jdh30.plus.com> writes:
> So, can I now handle closures in Lisp just as I would in any other FPL, i.e.
> downwards and upwards?
Yes. They work in both ways.
--
Thomas A. Russ, USC/Information Sciences Institute
Jon Harrop <······@jdh30.plus.com> writes:
> Pascal Bourguignon wrote:
>> Then you don't know C, where functions must be prefixed by &:
>>
>> #include <math.h>
>> typedef double(*fun)(double);
>> fun f = &sin;
>> int main(void){
>> printf("%f\n",f(1.0));
>> return(0);}
>
> Very true - should have said "functional language". Did Lisp always have
> closures?
No. I think this comes with lexical scopes.
In emacs lisp, there's no closure.
(funcall
(let ((x 1))
(lambda () x)))
--> Debugger entered--Lisp error: (void-variable x)
(lambda nil x)()
--
__Pascal Bourguignon__ http://www.informatimago.com/
Small brave carnivores
Kill pine cones and mosquitoes
Fear vacuum cleaner
Pascal Bourguignon wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>
> > Very true - should have said "functional language". Did Lisp always have
> > closures?
>
> No. I think this comes with lexical scopes.
> In emacs lisp, there's no closure.
>
> (funcall
> (let ((x 1))
> (lambda () x)))
>
> --> Debugger entered--Lisp error: (void-variable x)
> (lambda nil x)()
I was hoping one of the ancient Lisp hackers would speak up; perhaps
they have abandoned this thread. The issue of closures in a dynamic
environment predates Algol 60.
I believe it is true that lexical scoping allows closures to be
generated "cleanly" which is why they were preferred for Scheme and
Common Lisp in the "modern" era. I believe also that older dynamically
scoped Lisps often allowed the generation of closures, with slightly
different properties and writing style. Keywords rattling around in my
head are "funarg" and "upward funarg".
Problems that could be encountered included the issues of inadvertent
name clashes in dynamic scope, as well as whether interpreted and
compiled code are required to have the same semantics.
This is well-trod ground, but I've never visited the place myself.
Stefan Ram wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
> >Then you don't know C, where functions must be prefixed by &:
> >#include <math.h>
> >typedef double(*fun)(double);
> >fun f = &sin;
>
> I understand the following quotation from ISO/IEC 9899:1999
> (E) as saying that this ampersand is not required.
>
> »Except when it is the operand of the sizeof operator or
> the unary & operator, a function designator with type
> ``function returning type'' is converted to an expression
> that has type ``pointer to function returning
> (...)type''.«
>
> ISO/IEC 9899:1999 (E), 6.3.2.1, [#4]
>
> (An additional "#include <stdio.h>" should be added to
> the above program.)
Correct on all points. It would be best written like this:
#include <stdio.h>
#include <math.h>
typedef double(*fun)(double);
fun f = sin;
int main(void){
printf("%f\n",f(1.0));
return(0);
}
but both "sin" and "&sin" are legal.
It's also worth mentioning that "f(1.0)" is legal, but so is
"(*f)(1.0)" and "(************f)(1.0)" is also correct. This is
because of the meaning of braces forming a function call.
C is a little odd in dealing with function pointers.
Stefan Ram wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
> >Correct on all points. It would be best written like this:
> > (...) return(0); (...)
> >but both "sin" and "&sin" are legal.
>
> Yes, and the parentheses in "return(0);" are not required
> as the whole "return(0);" can be omitted in main.
>
> >C is a little odd in dealing with function pointers.
>
> I have written this small program which shows an example of an
> application of function pointers to call functions by their
> names given as strings (a tiny interpreter).
>
> The preprocessor is used to build a list of function
> definitions, a list of function pointers and a list of
> function names using the same macro "FUNCTIONS" which is
> taking a kind of "functional argument" (funarg) "F" that is "r
> n b" first, then "n," and finally "#n,". So to add another
> function, one just has to insert a line before "/**/" and does
> not have to change anything else in the rest of the program.
>
> /*
> < filename = [stringcall.c]
> encoding = [ANSI_X3.4-1968]
> notation = [ISO/IEC 9899:1999 (E)]
> author = [Stefan Ram] > */
>
> #include <stdio.h> /* puts */
> #include <string.h> /* strcmp */
>
> #define F(r,n,b) r n b
> #define FUNCTIONS \
> F( void, beta, (){ puts( "Bravo" ); } )\
> F( void, zeta, (){ puts( "Zulu" ); } )\
> /**/
> FUNCTIONS
> #undef F
>
> #define F(r,n,b) n,
> void( * const function[] )() ={ FUNCTIONS };
> #undef F
>
> #define F(r,n,b) #n,
> char const * const name[] ={ FUNCTIONS };
> #undef F
>
> int const top = sizeof name / sizeof 0[ name ];
> void call( char const * const n )
> { for( int i = 0; i < top; ++i )
> if( !strcmp( n, i[ name ]))i[ function ](); }
>
> int main( void ){ call( "beta" ); call( "zeta" ); }
Cool. I didn't know you could do that like that. It's a bit confusing
though, I'd have to add a lot of comments before I could gaurantee I'd
understand it at any time of day or night.
You may be interested in the way Emacs works, I think it does something
similar.
···@zedat.fu-berlin.de (Stefan Ram) writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>>Then you don't know C, where functions must be prefixed by &:
>>#include <math.h>
>>typedef double(*fun)(double);
>>fun f = &sin;
>
> I understand the following quotation from ISO/IEC 9899:1999
> (E) as saying that this ampersand is not required.
>
> �Except when it is the operand of the sizeof operator or
> the unary & operator, a function designator with type
> ``function returning type'' is converted to an expression
> that has type ``pointer to function returning
> (...)type''.�
>
> ISO/IEC 9899:1999 (E), 6.3.2.1, [#4]
>
> (An additional "#include <stdio.h>" should be added to
> the above program.)
Sorry, I stopped really programming in C before 1999, and now I live
happily forever with lisp :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Pascal Bourguignon wrote:
> Sorry, I stopped really programming in C before 1999, and now I live
> happily forever with lisp :-)
Yes, it seems that neither of us know C. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Pascal Bourguignon wrote:
> > Sorry, I stopped really programming in C before 1999, and now I live
> > happily forever with lisp :-)
>
> Yes, it seems that neither of us know C. :-)
C is old school anyway. The new way is assembler ;-)
--
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want. I'll make more!
Jon Harrop <······@jdh30.plus.com> writes:
> Well, I've never come across a language where you can't just refer to a
> function by name but you have to prefix it with "funcall", "function", "#'"
> or whatever.
You've never used a language with different namespaces for different
constructs?
> From someone else's post, I get the impression that the reason
> for having to do this in Lisp is a complicated interaction with run-time
> code generation.
No, it is a simple issue of multiple namespaces.
Joe Marshall wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Well, I've never come across a language where you can't just refer to a
>> function by name but you have to prefix it with "funcall", "function",
>> "#'" or whatever.
>
> You've never used a language with different namespaces for different
> constructs?
Not for different kinds of values when you want all values to be first
class, AFAIK.
>> From someone else's post, I get the impression that the reason
>> for having to do this in Lisp is a complicated interaction with run-time
>> code generation.
>
> No, it is a simple issue of multiple namespaces.
Ok.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Joe Marshall wrote:
>> Jon Harrop <······@jdh30.plus.com> writes:
>>> Well, I've never come across a language where you can't just refer to a
>>> function by name but you have to prefix it with "funcall", "function",
>>> "#'" or whatever.
>>
>> You've never used a language with different namespaces for different
>> constructs?
>
> Not for different kinds of values when you want all values to be first
> class, AFAIK.
It has nothing to do with the kind of value. It has to do with the
syntax of a lisp expression.
Jon Harrop <······@jdh30.plus.com> writes:
> Well, I've never come across a language where you can't just refer to a
> function by name but you have to prefix it with "funcall", "function", "#'"
> or whatever.
Well, in Common Lisp, you CAN refer to a function just by its name, as
long as you do it in the proper context. When a symbol appears as the
first element of a form, the function value is used. It is only when it
is used as an argument to some other function that you need to use the
more complicated reference methods.
Do the other languages you know all prohibit you from using an
identifier that names a function as a variable name? Or does having a
variable with that name just make the function inaccessible?
For an interesting example of this, look at
(let ((sin #'/))
(list (funcall sin 0.5)
(funcall #'sin 0.5)))
==> (2.0 0.47942555)
--
Thomas A. Russ, USC/Information Sciences Institute
Jon Harrop wrote:
> I'm currently having problems with a "fold" that I've defined. I think I
> need to put #' before the name of the function argument, but I've no idea
> why. :-(
fold is just a variable (defined with let or defvar, or a function
parameter). If it's a function, you can funcall it.
If you want the function called fold (defined with flet or defun), you
have to use (function fold), or in short: #'fold .
--
Do or do not. There is no try.
Yoda
Ulrich Hobelmann wrote:
> Jon Harrop wrote:
>> I'm currently having problems with a "fold" that I've defined. I think I
>> need to put #' before the name of the function argument, but I've no idea
>> why. :-(
>
> fold is just a variable (defined with let or defvar, or a function
> parameter). If it's a function, you can funcall it.
>
> If you want the function called fold (defined with flet or defun), you
> have to use (function fold), or in short: #'fold .
Right, but I don't have to do that with "fold" but I do have to do that with
the auxiliary function that I pass to fold. I think I see why. I'm not sure
why #' is shorthand for "(function ...)".
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop wrote:
> Ulrich Hobelmann wrote:
>
>>If you want the function called fold (defined with flet or defun), you
>>have to use (function fold), or in short: #'fold .
>
>
> Right, but I don't have to do that with "fold" but I do have to do that with
> the auxiliary function that I pass to fold. I think I see why. I'm not sure
> why #' is shorthand for "(function ...)".
So, you've trolled this newsgroup for months with your opinions about CL
without actually having learned any? I mean, #' and FUNCTION are covered
on page 60 of PCL.
I've personally read significantly more than 60 pages on OCaml , H-M
and the like, and still would not think myself informed enough to be
debating the merits of the approach with experts in that field.
Do as all a favour, learn enough CL so that your opinion is at least
slightly more informed before coming back and spouting off about it.
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
On Tue, 27 Sep 2005 19:29:56 GMT, drewc <·····@rift.com> wrote:
> So, you've trolled this newsgroup for months with your opinions
> about CL without actually having learned any?
You're surprised? I think it was more or less obvious from day one
that he didn't care about anything that didn't support his views.
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Tue, 27 Sep 2005 19:29:56 GMT, drewc <·····@rift.com> wrote:
>
>
>>So, you've trolled this newsgroup for months with your opinions
>>about CL without actually having learned any?
>
>
> You're surprised? I think it was more or less obvious from day one
> that he didn't care about anything that didn't support his views.
Flabbergasted! I guess the troll mentality is something i will never
understand. Why waste months of ones own time only to remain ignorant?
Why come in to cll at all, ask a whole bunch of questions of which one
doesn't care about the answers, publically display ones ignorance and
apathy, and gain nothing but the disrespect of ones peers?
It boggles the mind. Is it just a ploy for attention? Is there any
literature on the subject (of trolls) than anybody can recommend?
> Cheers,
> Edi.
>
--
Drew Crampsie
drewc at tech dot coop
"Never mind the bollocks -- here's the sexp's tools."
-- Karl A. Krueger on comp.lang.lisp
drewc <·····@rift.com> writes:
> Flabbergasted! I guess the troll mentality is something i will never
> understand. Why waste months of ones own time only to remain ignorant?
Not to mention that some trolls bash Lisp in Lisp forums, i.e. where
people are less likely to care or switch language.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
drewc wrote:
> Edi Weitz wrote:
> > On Tue, 27 Sep 2005 19:29:56 GMT, drewc <·····@rift.com> wrote:
> >>So, you've trolled this newsgroup for months with your opinions
> >>about CL without actually having learned any?
> >
> >
> > You're surprised? I think it was more or less obvious from day one
> > that he didn't care about anything that didn't support his views.
>
> Flabbergasted! I guess the troll mentality is something i will never
> understand. Why waste months of ones own time only to remain ignorant?
>
> Why come in to cll at all, ask a whole bunch of questions of which one
> doesn't care about the answers, publically display ones ignorance and
> apathy, and gain nothing but the disrespect of ones peers?
>
> It boggles the mind. Is it just a ploy for attention? Is there any
> literature on the subject (of trolls) than anybody can recommend?
>From the troller's mouth:
http://linux.nullcode.org/troll.txt
Tayssir
--
SNL Conspiracy Theory Rock video:
http://www.milkandcookies.com/links/29719/details/
From: David Steuber
Subject: Re: Why Bother Trolling? (was Re: A simple interpreter)
Date:
Message-ID: <877jcz197e.fsf@david-steuber.com>
Matthias <··@spam.please> writes:
> Another, equally interesting question is why the Lisp community so
> happily and for such long times continues to feed the trolls.
Bait them, trap them, tag them, release them back into the wild.
It's like a National Geographic special.
--
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want. I'll make more!
David Steuber <·····@david-steuber.com> writes:
> Matthias <··@spam.please> writes:
>
>> Another, equally interesting question is why the Lisp community so
>> happily and for such long times continues to feed the trolls.
>
> Bait them, trap them, tag them, release them back into the wild.
>
> It's like a National Geographic special.
``I'll wait here behind this blind while Jim Fowler subdues the
troll...''
Joe Marshall wrote:
> David Steuber <·····@david-steuber.com> writes:
>
>
>>Matthias <··@spam.please> writes:
>>
>>
>>>Another, equally interesting question is why the Lisp community so
>>>happily and for such long times continues to feed the trolls.
>>
>>Bait them, trap them, tag them, release them back into the wild.
>>
>>It's like a National Geographic special.
>
>
> ``I'll wait here behind this blind while Jim Fowler subdues the
> troll...''
>
You are safe behind that blind, and with Mutual of Omaha everyone can be
safe ....
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Edi Weitz <········@agharta.de> writes:
> On Tue, 27 Sep 2005 19:29:56 GMT, drewc <·····@rift.com> wrote:
>
> > So, you've trolled this newsgroup for months with your opinions
> > about CL without actually having learned any?
>
> You're surprised? I think it was more or less obvious from day one
> that he didn't care about anything that didn't support his views.
So /that's/ why he puts the Dr in front of his name in his .sig.
--
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want. I'll make more!
Jon Harrop <······@jdh30.plus.com> writes:
> That's excellent. However, I'd rather the target language was not a
> close relative of either Lisp or ML. Scheme is very close to Lisp,
> so Lisp would clearly have a huge advantage here. BASIC would be
> quite nice but the interpreter that I found doesn't seem to leverage
> Lisp's features and I can't get it to run.
OK, so as an earlier poster suggested, use the Prolog compiler from
Norvig's book PAIP. The code for this is available online.
-russ
Jon Harrop <······@jdh30.plus.com> writes:
> Pascal Costanza wrote:
>> Try Pseudoscheme: http://mumble.net/~jar/pseudoscheme/
>>
>> It's not actually an interpreter but rather a compiler, but I think it
>> shows well how to embed a different language in Common Lisp.
>
> That's excellent. However, I'd rather the target language was not a close
> relative of either Lisp or ML. Scheme is very close to Lisp, so Lisp would
> clearly have a huge advantage here.
>
> BASIC would be quite nice but the interpreter that I found doesn't seem to
> leverage Lisp's features and I can't get it to run.
I'm sorry to hear that.
Indeed, it seems an error crept in: the package nickname is missing.
Just add: (:nicknames "BASIC") to the defpackage.
[19]> (load"/home/pjb/src/public/small-cl-pgms/basic/basic.lisp")
;; Loading file /home/pjb/src/public/small-cl-pgms/basic/basic.lisp ...
;; Loaded file /home/pjb/src/public/small-cl-pgms/basic/basic.lisp
T
[20]> (COM.INFORMATIMAGO.COMMON-LISP.BASIC:main)
*** QUICK-DIRTY-AND-UGLY BASIC, VERSION 0.1 ***
COPYRIGHT PASCAL BOURGUIGNON 2003
QUICK-DIRTY-AND-UGLY BASIC COMES WITH *ABSOLUTELY NO WARRANTY*.
THIS IS FREE SOFTWARE, AND YOU ARE WELCOME TO REDISTRIBUTE IT
UNDER THE CONDITIONS LISTED IN THE GNU PUBLIC LICENSE.
> 10 for i=1 to 10
> 20 print i
> 30 next i
> rnu
ERROR: INVALID TOKEN COM.INFORMATIMAGO.COMMON-LISP.BASIC::RNU IN STATEMENT.
> run
1
2
3
4
5
6
7
8
9
10
>
Note, it's a QUICK-DIRTY-AND-UGLY-AND-BUGGY BASIC. Not worth its
magnetic field.
Now, you're saying that it doesn't leverage lisp facilities. I don't
entirely agree. Even if it's a small one-afternoon joke, it still use
a couple of macros, and for example, the expression grammar is
specified in a declarative way:
(MAKE-PARSE-LEVEL FACT (^) SIMP)
(MAKE-PARSE-LEVEL TERM (* / MOD) FACT)
(MAKE-PARSE-LEVEL EXPR (+ -) TERM)
(MAKE-PARSE-LEVEL COMP (< <= > >= = <>) EXPR)
(MAKE-PARSE-LEVEL CONJ (AND) LNOT)
(MAKE-PARSE-LEVEL DISJ (OR) CONJ)
(MAKE-COMPARISON BLT < < STRING< )
(MAKE-COMPARISON BLE <= <= STRING<=)
(MAKE-COMPARISON BGT > > STRING> )
(MAKE-COMPARISON BGE >= >= STRING>=)
(MAKE-COMPARISON BEQ = = STRING= )
(MAKE-COMPARISON BNE <> /= STRING/=)
--
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Pascal Bourguignon wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> BASIC would be quite nice but the interpreter that I found doesn't seem
>> to leverage Lisp's features and I can't get it to run.
>
> I'm sorry to hear that.
> Indeed, it seems an error crept in: the package nickname is missing.
> Just add: (:nicknames "BASIC") to the defpackage.
Heh, I have so much Lisp to learn. :-)
> Note, it's a QUICK-DIRTY-AND-UGLY-AND-BUGGY BASIC. Not worth its
> magnetic field.
Do you think it is worth comparing it to an OCaml implementation? Now that
I've got it working it seems like by far my best option...
> Now, you're saying that it doesn't leverage lisp facilities. I don't
> entirely agree. Even if it's a small one-afternoon joke, it still use
> a couple of macros, and for example, the expression grammar is
> specified in a declarative way:
>
> (MAKE-PARSE-LEVEL FACT (^) SIMP)
> (MAKE-PARSE-LEVEL TERM (* / MOD) FACT)
> (MAKE-PARSE-LEVEL EXPR (+ -) TERM)
> (MAKE-PARSE-LEVEL COMP (< <= > >= = <>) EXPR)
> (MAKE-PARSE-LEVEL CONJ (AND) LNOT)
> (MAKE-PARSE-LEVEL DISJ (OR) CONJ)
>
>
> (MAKE-COMPARISON BLT < < STRING< )
> (MAKE-COMPARISON BLE <= <= STRING<=)
> (MAKE-COMPARISON BGT > > STRING> )
> (MAKE-COMPARISON BGE >= >= STRING>=)
> (MAKE-COMPARISON BEQ = = STRING= )
> (MAKE-COMPARISON BNE <> /= STRING/=)
Very interesting. Perhaps is the killer example I've been looking for,
thanks. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
Jon Harrop <······@jdh30.plus.com> writes:
> Does anyone know of a suitably simple interpreter written in Lisp (say <
> 2kLOC) than I can port to OCaml in order to compare the effort required to
> write an interpreter in these languages and the resulting performance?
I think the scheme interpreter/compiler from Norvigs PAIP might be
what you are looking for.