Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Elica

#1
Whither newLISP? /
October 05, 2009, 05:22:28 AM
Lutz is absolutely right. I'm now finishing a Logo compiler (internally Logo is very close to Lisp), so to support its dynamic features (like defining variables and functions at run time) it has incremental JIT-like compilation.



The fact that datatype is a property of the datum, not a property of the variable adds some extra checks whenever the datum is being used.



Also, support for dynamic and syntax scopes adds some difficulties.



In a nutshell, in an ordinary non-dynamic program there is a huge increase of performance. In a very dynamic program (which modifies itself at run-time) the performance could be worse than that of an interpreter.



Fortunately, most programs in Logo do not use the dynamic features of the language, like constructing a list of command and then executing it. So, a compiler gives a pleasant speed improvement for the average users.



Unfortunately a compiler for Logo (and Lisp) will put its developer in the programming hell, so if Lutz is a software masochist (like me), he can give it a try :)



Making a compiler for languages like C and Pascal is a lot easier and straightforward.
#2
Anything else we might add? /
September 19, 2009, 12:13:05 PM
This is the first time ever I used a dictionary while reading a Lisp program. Honestly. :)
#3
Whither newLISP? /
September 15, 2009, 05:13:28 AM
Six years ago I presented a paper about how Elica displays source code to help users find errors. The paper is available http://elica.net/download/papers/ErrorReportingInElica.pdf">here. You may have a look at figures:



Fig.4 - a summary of supported representations of source code

Fig.5 - fully parenthesised original Logo source

Fig.6 - graphical non-ASCII brace notation

Fig.7 - graphical non-ASCII box notation

Fig.8 - prefix-only Lisp-like indented notation



Of course, the paper is about Logo, but all results are immediately applicable to Lisp.





PS. There are other representations, but they are not related to the discussion, like assembler representation or natural language representation.
#4
Whither newLISP? /
September 12, 2009, 10:35:31 AM
Try to code this:  "if a is integer and b is integer then print 'yes'."
#5
Anything else we might add? /
September 11, 2009, 04:23:53 AM
Although not a true newlisper, here is a recursive version of me (when I was younger):





http://www.noe-kaleidoscope.org/group/nms_acc/img/researchers/pb-1.jpg">
#6
Whither newLISP? /
September 11, 2009, 04:17:31 AM
If the idea of reducing the number of (...)'s is to make the source code easier to read by not-lispers, then you must also consider solutions which affect the IDE (or the editor) without changing anything in the language.



For example, an editor that helps with the (..)'s might solve most of the problems. Here are few options:



- changing font size/color/background

- adding graphical elements (like the box in Boxer)

- collapsing/expanding nodes and subnodes

- etc. etc.



This would keep the language pure and will move all human-computer interfacing problems to be solved by the GUI or IDE.



So, a key question is whether you like an ASCII-only solution, or you would be happy with other solutions too. For ASCII solutions the most feasible might be using macros or preprocessing.
#7
Whither newLISP? /
August 31, 2009, 11:25:28 AM
There is one easy recursive solution, but I'm afraid you will not like it, although you may enjoy it. Here it goes:



To solve the problem with parentheses, we can replace them by square brackets. However, this will introduce a new problem - a problem with the square brackets. To solve it, we can replace brackets with parentheses, which will reraise the initial problem. Fortunately, we already know how to solve it.



So, everything is OK - the initial problem is reduced to a sequence of problems, each of which can be solved trivially.
#8
Quote from: "newdep"When long enough removing parentheses from lisp you will endup killing lisp.


If you remove parentheses carefully you will not kill Lisp, but will end up with Logo.



A Lisp with reduced number of parentheses may appear simpler to novice users, but will definitely be harder to implement (from developer's point of view). For example, the last two Logo dialects which I implemented both had a hidden conversion from Logo to Lisp-like prefix-only full-paranthesised notation which is then used by the compiler/interpreter.
#9
Whither newLISP? /
August 04, 2009, 11:34:50 AM
This looks like a preprocessor inside of an event handler. So, practically, your code treats "x IS y" as data and processes it into something more digestible. Will this work if the commands are inside a text file mixed up with other lisp commands?
#10
Whither newLISP? /
August 04, 2009, 04:57:13 AM
A little bit too late, but here are my two cents on the topic of benckmarks (I did a lot for the Lhogho compiler).



1. I think it is impossible to write a satisfactory one-liner for benchmarking.



2. A true benchmark does not produce a scalar (i.e. a single value), but a vector - i.e. there are many individual performance values, measuring different aspects. For example, scores are for integer arithmetics, for fp arithmetics, for string manipulation, for memory management, for passing parameters, for searching local variables, etc. etc.



3. Except for a vector of many specialized mini-benchmarks, there is an option to use a more complex system, which measures a predefined set of functions. For example, a test for calculation a recursive math function spends time for real calculaitons, for passing parameters, for low-level function invokation, and so on.



4. Simple/short benchmarks can be seriously affected by the Operating system (especially what it is doing in the background while you do the becnmark)



5. The way a code is compiled can also lead to drastically different results. For example, if newLisp is compiled with and without optimizations, this may lead to noticeable difference in performance.



6. What does one-line mean in a language where newlines are just whitespaces?



7. For a one-liner that measure integer arithmetics you can try the 3x+1 problem.
#11
Whither newLISP? /
August 03, 2009, 12:54:23 PM
It is a 20-30 lines long program which defines IS in a way that simple sentences like "x IS y" are valid programming commands.
#12
Whither newLISP? /
August 03, 2009, 09:34:34 AM
If Lisp were not stuck with the prefix-only notation, it would be possible to recreate the following toy-program:


mike is tall
john is tall
peter is old
john is old

what is john          ; => john is tall and old

john is smart
what is john          ; => john is tall, old and smart
who is smart          ; => john is smart
who is old            ; => peter and john are old

mike is old
who is old            ; => peter, john and mike are old


Yes, the text in the example is the real program, the results are shown after the "=>" signs.



The trick is that "x IS y" is a binary operator, which does this:



if x=WHO then search for all nodes which point to y

if x=WHAT then search for all nodes which are pointed to by y

otherwise add a new rule that node x points to node y



FYI: this example is taken from the Elica Museum.
#13
Whither newLISP? /
July 29, 2009, 03:11:29 AM
Quote from: "pjot"Do you know how many lines of code one needs for a simple 'Hello world' application in C++?


The same number of lines as in C.


#include <iostream>
 
int main()
{
    std::cout << "Hello, world!n";
}


More examples including some funny languages are available in http://en.wikibooks.org/wiki/List_of_hello_world_programs">Transwiki:List of hello world programs
#14
Whither newLISP? /
July 15, 2009, 11:19:53 AM
Just curious about C++ libraries which do use OOP within their APIs. How would one deal with stuff like this?
#15
Whither newLISP? /
June 20, 2009, 02:51:50 PM
I'm afraid you are interpreting my words too literally. There is no need of medical intervention, no wires, no chips. You've watched too many crap SciFi movies.



Just kidding, of course.



What I imagine will be interface which is not bound to physical connection in the conventional meaning. Let's say you can control a device with your thoughts, or your gestures, or your face expression, or whatever you may think of.



Also, I'm not sure that there will be any programming at all (the way we understand it now). No languages with grammars and syntax rules, no proceses like "compiling", "linking", etc.



Just imagine 30-40 years ago someone asking: "What is the future of computer cards? How will a computer card in 2000 look like? Will they be still rectangle? Will the holes be still arranged in a grid?"



http://www.vampandtramp.com/finepress/h/hanmer-Beaut-L.jpg">//http://www.vampandtramp.com/finepress/h/hanmer-Beaut-L.jpg





But it all depends on the definition of "future". For me, "future" is 100 years from now. And to be perfectly honest, I'm not sure there will be computers in 2109!!!