Thread: RE: [GD-General] Objective Caml (was Ruby opinions)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Brian H. <bri...@py...> - 2001-12-27 20:23:41
|
> 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 |
|
From: Jesse J. <jes...@mi...> - 2001-12-27 23:53:18
|
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
|
|
From: Patrick M D. <pa...@wa...> - 2001-12-28 01:55:16
|
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 |
|
From: Jesse J. <jes...@mi...> - 2001-12-28 03:59:30
|
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
|
|
From: Brian H. <bri...@py...> - 2001-12-28 04:58:10
|
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 |
|
From: Patrick M D. <pa...@wa...> - 2001-12-28 01:47:00
|
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 |
|
From: Brian H. <bri...@py...> - 2001-12-28 01:57:32
|
> 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
|
|
From: Patrick M D. <pa...@wa...> - 2001-12-28 03:19:48
|
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
|
|
From: Thatcher U. <tu...@tu...> - 2001-12-28 04:45:04
|
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 |
Thanks for helping keep SourceForge clean.
X