quote: Original post by bishop_pass

This LISP statement: (+ (5 6)) adds 5 and 6 together.

However, (+ (5 6)) is also a LISP data structure. It is a list containing 2 items: + and (5 6). The first item is an atom or symbol, and the 2nd item is another list, containing 2 items: 5 and 6.

What is the significance of this? The program can disect it''s own code. It can actually determine what it is doing. It can also create its own code on the fly.

Whoa. I''ve argued for good reflective capabilities in my earlier posts, but this goes MUCH further than anything I had in mind. I agree, this could be very, very cool. But if you can start generating code at runtime, how does your app get compiled? Won''t this stuff induce a rather significant overhead? Not that we care about performance in this particular discussion, but still...

quote: Original post by Wilka

I thought it was a good idea, but not like the C/C++ one. It should be something that lets you write code that writes code. You can get a lot of funky stuff going with C++ templates, but the compiler errors are icky and there''s not way to properly debug it cos it runs when you compile it. And it''s not very readable when you complex stuff going on.

Sounds like an issue that could (again) be solved using reflection (see bishop_pass'' post!). If reflection can solve your problems, would you still want to have a similar compile-time mechanism such as templates?

My idea of the perfect language is one where you have as much control as in asm, but you should still be able to write stuff on a higher level if you want to, and it should be somewhat easy. As far OO or not, I''m not that big a fan of OOP, but I wouldn''t mind it

/Mikael Jacobson

LISP (and scheme, ML, etc.) lambda expressions tend to be compiled into continuations. The continuations tend to work much in the same way as a call to a standard C function, except that the calling convention is very different, but with similar speed. A dynamically generated lambda expression would consist of a pre-compiled continuation combined with a set of implicit arguments to be placed on the stack. So something like:
(lambda (y) (lambda (x) (+ x y))) 3
would compile into two continuations, the first continuation being something like:

call +:2 # call + on the two top most elements of the stack

The second continuation would be like:

n = new dynamic_contiuation(1) # create a dynamic continuation with one element
n->arg(1) = top # the static argument of the dynamic continuation is the argument passed to this continuation
n->cont = cont_FFAS235 # the static continuation be the previously defined continuation (cont_FFAS235 being the compiler handle for it
push n # place n on the stack

So calling a dynamically created function at runtime is slightly more expensive than calling a compiled function, however, it''s not as expensive as full compilation.

Now actual symbols are stored as references to a symbol table. So referencing values by symbol is no more expensive really than using a singly indirected pointer.

quote: Original post by delphi3d

Whoa. I''ve argued for good reflective capabilities in my earlier posts, but this goes MUCH further than anything I had in mind. I agree, this could be very, very cool. But if you can start generating code at runtime, how does your app get compiled? Won''t this stuff induce a rather significant overhead? Not that we care about performance in this particular discussion, but still...

Some LISP basics and symbolic processing:

(this is a list)
The above is a list containing 4 items, each symbols: this, is, a, list.

((apples oranges) (carrots cauliflower))
The above is a list containing 2 items, each lists.

()
The above is a list containing 0 items. It is also NIL or NULL.

(the quick red fox)
The second item of the above list is ''quick''.
The fifth item of the above list is NIL.
The tenth item of the abvoe list is NIL.

(setf tools (list ''hammer ''screwdriver))
The above statement is a list. It is also a program statement.
The above statement is evaluated like this:
The function ''list'' creates a list and returns:
(hammer screwdriver).
The function ''setf'' sets the symbol ''tools'' to equal the list
(hammer screwdriver).

How about this:
(setf somecode ''(setf tools (list ''hammer ''screwdriver)))
The symbol ''somecode'' now equals the list which is:
(setf tools (list ''hammer ''screwdriver))

Now try the statement:
(eval somecode)

I''m probably really bad at explaining this but LISP revolves around the concept of lists which are stored as conscells.

A conscell has two pointers; a pointer pointing to the next conscell in the list and a pointer pointing to the item referenced by this conscell. Each item describes itself as a symbol, a basic type like a number, or another list.

A bit off topic, but relevant question: What is the actual definition of reflexive? I''ve heard in used in a lot of different contexts, but I''ll be damned if I can find an actual formal definition. Any takers?

Has anyone here heard of a language known as Euphoria?? It seems to be really well thought out and is pretty easy to learn and still doesn''t have a lot of overhead.

I think the website is:
http://www.rapideuphoria.com

I''m at work so can''t remember right off.


BeS
It's Da BOMB Baby!!!

Just for fun...
Anyone heard about Brainf*ck? It has 8 functions and works with array of integers. It is cool, but

''++++++++[->++++++++<]+.+.+.''
actually print "ABC"... I saw an hello world with this. Really hard to follow.
Here for a brief description of the language
Home page of Brainf*ck


Serious.
Pascal was my favorite, mainly because it was strongly typed, accepted preprocessors and had all the OOP features we need.
Ada is quite good, but I still prefer VB for the like.
For Web scripting, PHP is the best.

I think every languages have their own field of activity and only in those fields they are the best. C is certainly not the best for quickly developping application, and VB is not fast at run-time.

Why bother for ONE language to have it all? You just have to switch and it will do the job.

(( For those JavaDoc fans, you might want to look at Doc++, the same for C/C++ ))

We always want to prevent death, I always try to promote life instead.

LISP is a neat concept, but with all of those parenthesis and a new way of thinking, it sounds hard to become good at.

Euphoria looks good, and has some neat concepts. But creating a program for speed would need some thinking, since it does a lot of conversions between types, which could increase the overhead. It looks good for apps, but not for good games, especially since its graphics support is minimalist and requires DOS32. It''s also somewhat wordy; I prefer the C++ style of marking blocks of code (but that''s personal preference). It''s also not Object Oriented, which may not go well with some programmers. Why "--" for comments?

Brainf***, LOL. Even well-commented programs look impossible to decode. Let me go count the pluses in that program again . . . You sure this isn''t what they used to program Windows 95 with?


"Whoever performs only his duty is not doing his duty." --Bahya ibn Pakuda

quote: Original post by CobraA1

It looks good for apps, but not for good games, especially since its graphics support is minimalist and requires DOS32.

There is also Euphoria for Win32 & Linux and a port to BeOS in the works

quote:
Why "--" for comments?

As for this, I''m really not sure.

I have seen games programmed in Euphoria and they do pretty good actually. Last time I looked there was even someone making a DX wrapper for Euphoria Win32.

I guess I''ll have to hop over there and peruse around tonight as I haven''t been there in a while anyway.


BeS
It's Da BOMB Baby!!!

The Klingon programming language var''aq has to be the best. see the specifications here http://www.geocities.com/connorbd/varaq/varaqspec.html

-----------------------------
-cow_in_the_well

http://cowswell.gda.ods.org/

- Don't Panic -