gamedevlists-general

RE: [GD-General] Objective Caml (was Ruby opinions)

[Brian H. <bri...@py...>]

> This is a big practical problem with everything other than 
> C/C++.

And Obj-C =)  And Java's JNI interface, while not perfect, at least
works.  I know Eiffel has some mechanism, but I'm not sure how good it
is.  I've never liked Lua's interface.  That you need to use an external
tool like tolua indicates to me that it's just not doing things the
right way.

> Actually, one thing that bothers me is lack of a native 
> 32-bit float type.  floats in OCaml are 64-bit.  I think that 
> will need to get fixed at some point.

I think new languages (and their designers) strive real hard for
orthogonality and minimizing confusing types, and inevitably practical
considerations rear their heads.  The original DEC Alpha didn't support
byte operations, which made a lot of things REAL slow -- their attitude
was that the future is 64-bit, and dropping back to
conversion/pack/unpack for byte support was just going to be a temporary
thing =)

Not to go off on a tangent, I think Java ditching "unsigned" as a type
was probably a good idea.  IIRC Lua is missing integer support?  That's
a bit of an issue as well.  Or the belief that languages shouldn't have
preprocessors because the C preprocessor was so gross; inevitably you
lose major functionality like "#ifdef 0/#endif" and the language
designers defend it to the end.

Brian

RE: [GD-General] Objective Caml (was Ruby opinions)

[Jesse J. <jes...@mi...>]

At 12:23 PM -0800 12/27/01, Brian Hook wrote:
>Or the belief that languages shouldn't have
>preprocessors because the C preprocessor was so gross; inevitably you
>lose major functionality like "#ifdef 0/#endif" and the language
>designers defend it to the end.

Not necessarily. For example, Ruby allows you to stick executable 
code outside method definitions so you can do stuff like this:

if want_foo_method() # add foo() to our class if it's OK
    def foo(arg1, arg2)    # the foo method
       # code goes here
    end
end

I'm no Ruby guru yet, but it wouldn't surprise me if you could even 
do things like use a loop instead of an if statement and add a bunch 
of similar foo1, foo2, etc methods.

   -- Jesse

[GD-General] RE: Ruby

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Jesse Jones wrote:

> Not necessarily. For example, Ruby allows you to stick executable
> code outside method definitions so you can do stuff like this:
>
> if want_foo_method() # add foo() to our class if it's OK
>     def foo(arg1, arg2)    # the foo method
>        # code goes here
>     end
> end
>
> I'm no Ruby guru yet, but it wouldn't surprise me if you could even
> do things like use a loop instead of an if statement and add a bunch
> of similar foo1, foo2, etc methods.

TCL has similar functionality which can be very confusing because it
doesn't follow expected scoping rules.  Procedures declared within
procedures exist within the global namespace rather than locally as one
might expect.

I seem to recall that Ruby was a little smarter about this, building
closures to functions as appropriate.

Patrick

[GD-General] RE: Ruby

[Jesse J. <jes...@mi...>]

At 8:55 PM -0500 12/27/01, Patrick M Doane wrote:
>On Thu, 27 Dec 2001, Jesse Jones wrote:
>
>>  Not necessarily. For example, Ruby allows you to stick executable
>>  code outside method definitions so you can do stuff like this:
>>
>>  if want_foo_method() # add foo() to our class if it's OK
>>      def foo(arg1, arg2)    # the foo method
>>         # code goes here
>>      end
>>  end
>>
>>  I'm no Ruby guru yet, but it wouldn't surprise me if you could even
>>  do things like use a loop instead of an if statement and add a bunch
>>  of similar foo1, foo2, etc methods.
>
>TCL has similar functionality which can be very confusing because it
>doesn't follow expected scoping rules.  Procedures declared within
>procedures exist within the global namespace rather than locally as one
>might expect.
>
>I seem to recall that Ruby was a little smarter about this, building
>closures to functions as appropriate.

Ruby doesn't have free functions or nested functions. However you can 
define a method outside a class. If you do this the method is 
automatically added as a private method to the root object class 
which, for all intents and purposes, makes it a global function.

Ruby also has closures which are sort of like in-line nested 
functions that retain their context. The Ruby library classes make 
heavy use of these. Here's an example:

    def accumulate(collection, value = 0)
       collection.each {|entry| value += entry}
       return value
    end

The stuff between the braces is the closure. The each() method calls 
the closure for each item in the collection passing into the closure 
the current item (referenced as entry within the closure).

BTW one of the really cool things about Ruby is that classes aren't 
closed. For example, I was just bitching about std::string not having 
a back() method like *every* other sequential container in the 
standard library. In Ruby this would be trivial to fix. In C++ I have 
to use a free function or something gross like *(str.end() - 1).

   -- Jesse

Re: [GD-General] RE: Ruby

[Brian H. <bri...@py...>]

At 08:00 PM 12/27/2001 -0800, Jesse Jones wrote:
>BTW one of the really cool things about Ruby is that classes aren't closed.

Same with Obj-C.  You can extend an existing class, sans source code, by 
creating a "category".

@interface ClassToExtend (NewMethods)
- ( int ) newMethod;
@end

You then implement them in a separate implementation area (just like 
regular Obj-C classes), and from that point on you can call those new 
methods directly on the object:

ClassToExtend *c = [[ClassToExend alloc] init];

int i = [c newMethod]; //Call "newMethod" on a class that I didn't write

You can only change the interface, not the implementation, since changing 
the latter would cause a change in the class' size.  There can be some 
problems with name collisions if you're not careful.

Brian

[GD-General] Re: Preprocessors

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Brian Hook wrote:

> Or the belief that languages shouldn't have preprocessors because the
> C preprocessor was so gross; inevitably you lose major functionality
> like "#ifdef 0/#endif" and the language designers defend it to the
> end.

Or simply that they intend for you to use existing preprocessors.  There
is little to stop you from using the C preprocessor as a front-end for
most languages out there.

Patrick

[GD-General] RE: Preprocessors

[Brian H. <bri...@py...>]

> Or simply that they intend for you to use existing 
> preprocessors.

Fair enough, but then you have source code that won't recompile between
different build systems because of a different choice of preprocessors.
Imagine the hell we'd be in today if, for example, things like #if,
#define, #error, etc. were not standardized in the C language.

> There is little to stop you from using the C 
> preprocessor as a front-end for most languages out there.

Quite true.  Unfortunately others may opt to use no preprocessor, a
hacked preprocessor, or they'll use Perl and custom syntax, which ends
up causing problems.

In addition, for interpreted languages it may not be feasible to run a
preprocessor every time you want to load up and run some script.

Anyway, my point wasn't necessarily that this is insurmountable, since
it obviously is not, it's just that in my experience language designers
get really defensive about this topic.  There's this weird unwillingness
to admit that commenting out large blocks of code is actually useful.

Typically someone will tell you to use:

if ( 0 ) { put dead code here };

Unfortunately that dead code still needs to compile, so it doesn't help
when you have some weird parsing error and you're trying to find it.
For languages like Eiffel and Lua, which lack comment blocks, trying to
hunt down some parse error can be irritating.  Java at least still
retains /* */, although you can't nest them.

Of course, I'm sure some Emacs geek will suggest writing some custom
elisp that prepends each line in a selection with the appropriate line
comment, be it '--', '//', ';', or '#'.

Hell, for all I know Emacs already has a M-x comment-region-with-#
command =)

Brian

Re: [GD-General] RE: Preprocessors

[Patrick M D. <pa...@wa...>]

On Thu, 27 Dec 2001, Brian Hook wrote:

> > Or simply that they intend for you to use existing
> > preprocessors.
>
> Fair enough, but then you have source code that won't recompile between
> different build systems because of a different choice of preprocessors.
> Imagine the hell we'd be in today if, for example, things like #if,
> #define, #error, etc. were not standardized in the C language.

Users who want to use the code either use the same preprocessor or must
use the output of the preprocessor.  We have the C preprocessor already,
and can take advantage of reusing it.  Most systems should already have
one available.

A lot could be done for standardizing and improving build environments.
GNU make has done some very good work for Makefiles, but they are still
fairly difficult to learn and maintain.

> In addition, for interpreted languages it may not be feasible to run a
> preprocessor every time you want to load up and run some script.

Ah yes - I don't tend to give the interpreted world too much thought.

> Anyway, my point wasn't necessarily that this is insurmountable, since
> it obviously is not, it's just that in my experience language designers
> get really defensive about this topic.  There's this weird unwillingness
> to admit that commenting out large blocks of code is actually useful.

Hmm.. I'll agree with you about the defensive regarding preprocessors but
commenting out large blocks of code is lexical issue right?

> Typically someone will tell you to use:
>
> if ( 0 ) { put dead code here };
>
> Unfortunately that dead code still needs to compile, so it doesn't help
> when you have some weird parsing error and you're trying to find it.
> For languages like Eiffel and Lua, which lack comment blocks, trying to
> hunt down some parse error can be irritating.  Java at least still
> retains /* */, although you can't nest them.

So these languages have a relatively broken support for comments as you
need them.  Many languages do support nesting comments, especially more
recent ones.

> Of course, I'm sure some Emacs geek will suggest writing some custom
> elisp that prepends each line in a selection with the appropriate line
> comment, be it '--', '//', ';', or '#'.
>
> Hell, for all I know Emacs already has a M-x comment-region-with-#
> command =)

Absolutely, M-x comment-region will work great.  It works based on the
current language mode so you don't have to worry about the different
characters to use. :)

Patrick

Re: [GD-General] RE: Preprocessors

[Thatcher U. <tu...@tu...>]

On Dec 27, 2001 at 05:57 -0800, Brian Hook wrote:

> For languages like Eiffel and Lua, which lack comment blocks, trying to

In Lua, this works fine:

_ = [[
	commented out stuff....
]]

That's actually a block string assignment, to a variable called '_'.
Nests correctly as well.

-- 
Thatcher Ulrich <tu...@tu...>
http://tulrich.com