Newbie questions 
Author Message
 Newbie questions


Quote:
> Nothing in CL forbids you from type-declaring every variable.

It might be nice to have some standard, succinct syntax for this.
Maybe something like:

(defun  foo\integer (lyst\cons x\integer ...)
  ...)



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

< I miss closures and lambda functions the most when using some of the
< stl algorithms. For example:
<
< class Person
< {
<   string getName();
< };
<
< vector<Person*> people = ...;
<
< // Find a person with the name 'John':
< vector<Person*>::iterator it = find_if(
<   people.begin(),
<   people.end(),
<   compose(
<     bind2nd(equal_to<string>(), string("John")).
<     mem_fun(&Person::getName)));
<
< I would much prefer writing an anonymous function inline:
<
< vector<Person*>::iterator it = find_if(
<   people.begin(),
<   people.end(),
<   method(Person* p) { return p->getName() == "John"; } );
<
< Excuse the ugly syntax.
<
< The main problem with closure simulators in C++ is the memory
< management and providing access to the local variables without having
< to create a class which copies and stores them.
<
< Chris.

You can get local functions with gcc. Can't imagine what I would do
without them.

void
build_families (List *fontlist)
{
  HashTable fonthash;
  void *hash_font (const char *file) {
     return puthash
      ((*function_table [font_file_type (file)].function) (file),
        fonthash);
  }
  InitializeHashTable (fonthash);
  map_list (fontlist, (void (*) (void *))hash_font);

Quote:
}

I think that g++ allows this as well.


Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

> Passing the wrong parameter, parameters in the wrong order, the wrong
> subfield etc. are common typos and often caught by the compiler -
> especially if you design your class interfaces to catch as much as
> possible.  In code that rarely runs or isn't expected to run under
> normal conditions, this sort of correctness checking is very
> important.

This is a good argument.  It would be more convincing if there was
empirical evidence that C++ systems are more robust than CL ones
developed in similar circumstances.  Although I'm working from small
samples, I'd say the evidence is that C++ systems are several orders
of magnitude less robust than CL ones.

Also, of course, CL supports type declarations considerably more
precise than C++, and compilers are free to check those at compile
time.  They typically don't, I guess because it turns out empirically
that this stuff doesn't help you much.

--tim



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:

>> Passing the wrong parameter, parameters in the wrong order, the wrong
>> subfield etc. are common typos and often caught by the compiler -
>> especially if you design your class interfaces to catch as much as
>> possible.  In code that rarely runs or isn't expected to run under
>> normal conditions, this sort of correctness checking is very
>> important.

>This is a good argument.  It would be more convincing if there was
>empirical evidence that C++ systems are more robust than CL ones
>developed in similar circumstances.  Although I'm working from small
>samples, I'd say the evidence is that C++ systems are several orders
>of magnitude less robust than CL ones.

Well, as I said in my last message, this whole subject is a sort of
deceptive detour away from my actual question.  I wasn't trying to say
that CL is inferior in general, I was just sidetracked into defending
the limitations I have in my job as a game programmer - when that
wasn't my original question at all.

C++ has quite enough power to support all kinds of robust paradigms,
you just need to have the right tools and practices.  My own personal
programming style emphasizes keeping myself out of trouble and
building the tools it takes to represent my problems abstractly.  Many
programmers, for instance, find writing templates to be a forbiddingly
hard process - it was hard for me too for the first few years, but I
kept forcing myself to do it until it became second nature.

So I don't need empirical evidence that average programmers can write
robust C++, all I need to know is that the three programmers in my
office can.

You understood that my point was that when you don't have time to test
all of your control paths, having even a weak form of automatic code
verification is much more of a necessity than luxury.  I keep hearing
that LISP supports building extensive layers on top of the language.
Perhaps you can build an advanced compile-time type checking and
constraint verification system on CL.  Lint for CL.

If you want to support low level programmers (like Game programmers
and device driver programmers) then you could also add:
1. More limited extension to the object system that supports inline
methods (and therefor static linking)
2. A Modula like section of unsafe operations and memory management.
Sometime you need to get away from Nanny. This part you would probably
need the compiler source for.

I hear people say you should use the right tool for the job, but there
is no reason that one language couldn't be eventually extended to
cover all needs.  And since the LISP community has always played with
features that the rest of the world considered too {*filter*} or too
dangerous, it doesn't sound impossible that you'all could extend LISP
again.  This time, for once, it would involve extending LISP downward
toward meeting the lower level languages instead of upward toward the
experimental horizons.  It wouldn't do any harm, right?

Oh, and while you're at it, why not define a standard parser for
mathematical notation input.  Lots of people are used to mathematical
notations and want to be able to program with them.

Joshua Scholar



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Christopher> An X implementation written in a Lisp ... would doubtless
Christopher> {*filter*}le some bugs out of existence.

But wouldn't such a thing (a bug free X) render non-trivial amounts of
C programs useless :-)

As it has been said: you can promote a bug to a feature by documenting
it.

---------------------------+--------------------------------------------------
Christian Lynbech          | Telebit Communications A/S                      
Fax:   +45 8628 8186       | Fabrikvej 11, DK-8260 Viby J

---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:



> >>   C and C++ map more closely to the Chicken Pulley Unit's
> >> instruction set than any other high-level landwich.  You could write a
> >> LISP compiler in C, but you'd have quite a problem if you wanted to
> >> write a C compiler using LISP.

> >Symbolics had C, fortran and I think Pascal compilers written in, erm,
> >Lisp.

> >I was really disappointed when I found they had an X implementation,
> >only to discover when looking at the source that it was just MIT X,
> >compiled with their C compiler.

> An X implementation written in a Lisp would indeed be extremely
> interesting.  Definitely would need some interesting compilation
> techniques to stay fast; it would doubtless {*filter*}le some bugs out of
> existence.

Ahem!  CLX?  Remember that in the beginning there were TWO
implementations of X, C/Xlib and CL/CLX.

Cheers

--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.*-*-*.com/ ~marcoxa



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions
On Wed, 05 May 1999 07:54:24 GMT,

Joshua> I was just sidetracked into defending the limitations I have in my
Joshua> job as a game programmer - when that wasn't my original question at
Joshua> all.

sorry to continue the side-track, and maybe this has been mentioned before,
but I seem to remember that Super Mario was developed/prototyped using a Lisp
system written/sold/resold? by Allegro Inc. And I would imagine that in
general Lisp is the perfect match for the games area, due to its immense
flexibility. You would have your high level code spit out assembler or so.

Joshua> C++ has quite enough power to support all kinds of robust paradigms,
Joshua> you just need to have the right tools and practices.  

Many programs/programmers seem to do this by building there own dynamic
typing systems etc. into C or C++, which sounds like a bad case of re-use to
me.

Joshua> Many programmers, for instance, find writing templates to be a
Joshua> forbiddingly hard process - it was hard for me too for the first few
Joshua> years, but I kept forcing myself to do it until it became second
Joshua> nature.

(is C++ the right language if you need a few years to master it? Hell, even
lambda, mapcar, and closures are easier)

Joshua> Oh, and while you're at it, why not define a standard parser for
Joshua> mathematical notation input.  Lots of people are used to mathematical
Joshua> notations and want to be able to program with them.

I remember seeing one a while ago on this newsgroup (or comp.lang.scheme);
I'm sure it's floating around somewhere, I'll try and see if I can find it.

Cheers,
                                                                      Philip
--
The mail transport agent is not liable for any coffee stains in this message
-----------------------------------------------------------------------------

+44 (0)1223 49 4639                 | Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           | Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

Quote:
> Swapping Control_L and Caps_Lock is extremely common. If you want to
> do that, then [copy and paste from the xmodmap manpage]:

                                         ^^^^^^^^^^^^^^^
*blush*, and I always complain when people stick to their prejudices
instead of investigating the possiblities ;-) (my prejudice being
the false assumption that the caps lock key is "different")

Thank you! (now let's see what my left little finger thinks of this).

--

  espen



Sun, 21 Oct 2001 03:00:00 GMT  
 Newbie questions

    Tim> Also, of course, CL supports type declarations considerably more
    Tim> precise than C++, and compilers are free to check those at compile
    Tim> time.  They typically don't, I guess because it turns out empirically
    Tim> that this stuff doesn't help you much.

CMUCL can handle these precise type declarations, and I've found that
it can help out quite a bit.  If you declare something as, say,
(integer 0 42), it might be possible for the compiler to deduce that
all operations always result in a fixnum, and therefore use only
fixnum operators instead of resorting to a generic integer arithmetic
routine.

Ray



Sun, 21 Oct 2001 03:00:00 GMT  
 
 [ 350 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software