Invisible wrote:
> At a simple level, you could just scan the source when you compile it, 
> and replace any calls to the #ifTrue:ifFlase: method (and friends) with 
> the appropriate machine instructions.

Internally, that's what it does. Of course, if you send that to something 
that isn't a boolean, *then* you get an even bigger overhead.

> Then again, Smalltalk is an interpretted language. Speed is quite 
> clearly *not* its main objective.

This is not something that noticably slows things down, tho. When 
*everything* is a message dispatch, you can design your microcode to do that 
efficiently.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message

>> And then I learned Haskel, which is *completely different*. ;-)
> 
> Try then APL, or LISP, or FORTH.

Tried Lisp, didn't like it. Too much backwards compatibility making it 
way, way more complicated than it should be.

I guess that's one nice thing about Haskell's avoidance of success...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> At a simple level, you could just scan the source when you compile it, 
>> and replace any calls to the #ifTrue:ifFlase: method (and friends) 
>> with the appropriate machine instructions.
> 
> Internally, that's what it does. Of course, if you send that to 
> something that isn't a boolean, *then* you get an even bigger overhead.

Sure. If you had static typing, you could statically guarantee that this 
won't happen, and avoid handling it.

OTOH, Smalltalk basically allows you to define new flow control 
constructs of your own, so...

> This is not something that noticably slows things down, tho. When 
> *everything* is a message dispatch, you can design your microcode to do 
> that efficiently.

Oh, sure. Simplicity can be a boon to efficiency. I'm just saying, 
Smalltalk isn't targetted at scientific computing, realtime simulation, 
DSP or high-end computer gaming. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

If I ever did write a book on Haskell, would this make a good chapter?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Sure. If you had static typing, you could statically guarantee that this 
> won't happen, and avoid handling it.

Well, you'd still have to handle it, but at compile time, yes.

> OTOH, Smalltalk basically allows you to define new flow control 
> constructs of your own, so...

Anything with lambdas does, really.  (Well, real lambdas, not just downward 
funargs.)

> Oh, sure. Simplicity can be a boon to efficiency. I'm just saying, 
> Smalltalk isn't targetted at scientific computing, realtime simulation, 
> DSP or high-end computer gaming. ;-)

I think it was actually a teaching language.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message

Orchid XP v8 wrote:
> If I ever did write a book on Haskell, would this make a good chapter?
> 

Indeed!  Actually, it should be near the front, I think. (But I'm a computer 
language nerd, so maybe not.)

I'll second that you should write a Haskell book. I bet I know someone who 
could tell you the right person to point you at at O'Reilly if you wanted to 
see if it could go commercial, too.  I wouldn't give the rights away *too* fast.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> If I ever did write a book on Haskell, would this make a good chapter?
> 
> Indeed!  Actually, it should be near the front, I think. (But I'm a 
> computer language nerd, so maybe not.)

This was my thinking also. A chapter with no code, just concepts.

I've tried writing Haskell tutorials before, and I always get stuck 
here, because you need ADTs to explain pattern matching, but you need 
pattern matching to explain ADTs. I think explaining how it all works 
before trying to write code is probably the way forward. Indeed, I'm 
thinking this might significantly simplify other aspects too - teach 'em 
how it all works before you get into the details of syntax and so forth.

> I'll second that you should write a Haskell book. I bet I know someone 
> who could tell you the right person to point you at at O'Reilly if you 
> wanted to see if it could go commercial, too.  I wouldn't give the 
> rights away *too* fast.

Heh. O'Reilly just published one:

http://book.realworldhaskell.org/

It's written by three leading Haskell experts too.

Nice idea though. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> here, because you need ADTs to explain pattern matching, but you need 
> pattern matching to explain ADTs.

You don't need pattern matching to explain ADTs. Explain ADTs with math (and 
textual substitutions, etc), then explain how pattern matching expressions 
can help automate what to do.

Actually, Meyers did a really nice job of explaining ADTs to justify 
object-oriented ideas in his Eiffel book.

> how it all works before you get into the details of syntax and so forth.

Yes. Or intermix the two.

http://docs.eiffel.com/book/method/object-oriented-software-construction-2nd-edition

If you haven't read that, you should.

> Heh. O'Reilly just published one:

Oh. Try apress or something, then.

Haskell for Dummies.  I just don't know anyone at the other places.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> here, because you need ADTs to explain pattern matching, but you need 
>> pattern matching to explain ADTs.
> 
> You don't need pattern matching to explain ADTs. Explain ADTs with math 
> (and textual substitutions, etc), then explain how pattern matching 
> expressions can help automate what to do.
> 
> Actually, Meyers did a really nice job of explaining ADTs to justify 
> object-oriented ideas in his Eiffel book.

Meyers explained ABSTRACT Data Types, not ALGEBRAIC Data Types. 
Different ADT. ;-)

> http://docs.eiffel.com/book/method/object-oriented-software-construction-2nd-edition

> 
> If you haven't read that, you should.

I'm pretty sure I have read it.

Post a reply to this message

Invisible wrote:
> Meyers explained ABSTRACT Data Types, not ALGEBRAIC Data Types. 
> Different ADT. ;-)

No, he explained algebraic data types, *then* abstract data types.

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling togeher,
   but to different destinations.

Post a reply to this message