Warp <war### [at] tagpovrayorg> wrote:
>   So Haskell is really a two-paradigm language: Functional and modular?

The functions are defined inside of modules.  Modularity is a good thing
anywhere.

Post a reply to this message

Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Tue, 25 Mar 2008 17:34:14 +0100, Nicolas Alvarez  
> <nic### [at] gmailisthebestcom> wrote:
> > C++ STL vector template class has a specialization for 'bool' that uses  
> > 1 bit per element too. That is, a vector<bool> takes 1 bit per element.

> Yes, but that specialisation is largely considered a mistake

  The alternative would be that there's no specialization, in which
case each element could take even 4 bytes (from which only 1 bit is
actually used).

  I don't see any problem in having an efficient boolean vector.
If it doesn't work with some STL algorithms, then it doesn't. In
the vast majority of cases there isn't any logical use for STL
algorithms for a bool vector anyways (why would you, for example,
try to sort a bool vector? It doesn't make any sense).

  Of course std::bitset should be used whenever possible. However,
it's not always possible. In that case std::vector<bool> is the
next best thing.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> If you consider "modular" to be a programming paradigm then... yes, I 
> guess.

  Yes, modular programming is usually considered a programming paradigm
of its own (a type of precursor of object-oriented programming).

  I think that the quintessential example of a modular programming
language is Modula-2: Its modules are more or less full-fledged classes
(public and private parts, member variables and functions, instanciation,
references to such instances...), except for what would make it an
object-oriented programming language: Inheritance.

  (Modula-3 added inheritance, making it an OOP language.)

> (Does Pascal count as "module" too?)

  Pascal is a programming language, not a module. :P

> Did I mention that Haskell also has "classes"? (Though they don't work 
> quite the same as in OOP.)

  If you can inherit and have dynamic binding (or a messaging system,
ie. delegation) then it would more or less make it an OOP language,
else it's just a modular programming language.

-- 
                                                          - Warp

Post a reply to this message

>> If you consider "modular" to be a programming paradigm then... yes, I 
>> guess.
> 
>   Yes, modular programming is usually considered a programming paradigm
> of its own (a type of precursor of object-oriented programming).

I thought that was structured programming?

>   I think that the quintessential example of a modular programming
> language is Modula-2: Its modules are more or less full-fledged classes
> (public and private parts, member variables and functions, instanciation,
> references to such instances...), except for what would make it an
> object-oriented programming language: Inheritance.

I've heard legend of Modula-2. Never actually seen it though.

(Actually, I've heard legend of another functional language where 
apparently modules *do* have inheritance... There are often debates 
about whether Haskell should do this - with most people agreeing the 
vast increase in complexity isn't worth it.)

>> (Does Pascal count as "module" too?)
> 
>   Pascal is a programming language, not a module. :P

Gah! The difference a few characters makes... :-S

[Obviously I meant "does Pascal count as modular?"]

>> Did I mention that Haskell also has "classes"? (Though they don't work 
>> quite the same as in OOP.)
> 
>   If you can inherit and have dynamic binding (or a messaging system,
> ie. delegation) then it would more or less make it an OOP language,
> else it's just a modular programming language.

Dynamic binding? Sure. That's the entire purpose.

Inheritance? Mmm, not really, no.



[In Java, a class *is* a type. In Haskell, a class is something a type 
may or may not be a member of. For example, the "Show" class provides a 
"show" method. Any type that is a member of the Show class can be 
converted into a string by calling the show function. It is possible to 
make it so that no type can be a member of class X without first being a 
member of class Y - but that's not exactly inheritance.]

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

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> >> If you consider "modular" to be a programming paradigm then... yes, I 
> >> guess.
> > 
> >   Yes, modular programming is usually considered a programming paradigm
> > of its own (a type of precursor of object-oriented programming).

> I thought that was structured programming?

  Structured programming is more related to principles related to the
control flow of the program, ie. related to control structures (such as
conditionals, switch-blocks and different types of loops). It's a kind
of subset of the more general procedural programming paradigm.

  I don't think the concept of "module" is part of the structured
programming paradigm. A modular programming language may follow the
principles of structured programming (and make its own additions), but
that doesn't mean it's the same in the other way. And I don't think
there's any requirement for a modular language to use structured programming
principles (in the same way as an OOP language doesn't necessarily have
to follow procedural programming principles).

> (Actually, I've heard legend of another functional language where 
> apparently modules *do* have inheritance... There are often debates 
> about whether Haskell should do this - with most people agreeing the 
> vast increase in complexity isn't worth it.)

  I have never understood why adding *optional* features, which you are
in no way forced to use, to something would make it "too complex".

> >> (Does Pascal count as "module" too?)
> > 
> >   Pascal is a programming language, not a module. :P

> Gah! The difference a few characters makes... :-S

> [Obviously I meant "does Pascal count as modular?"]

  I don't know enough about Pascal to answer that question. (Is there
a "standard" Pascal language anyways? I have the impression that each
compiler company has created their own variant of Pascal, and that there's
no official standard. I may perfectly be wrong, of course.)

> >> Did I mention that Haskell also has "classes"? (Though they don't work 
> >> quite the same as in OOP.)
> > 
> >   If you can inherit and have dynamic binding (or a messaging system,
> > ie. delegation) then it would more or less make it an OOP language,
> > else it's just a modular programming language.

> Dynamic binding? Sure. That's the entire purpose.

> Inheritance? Mmm, not really, no.

  That's a bit contradictory given that dynamic binding (or its
alternative, delegation) is inherently related to inheritance.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   Structured programming is more related to principles related to the
> control flow of the program, ie. related to control structures (such as
> conditionals, switch-blocks and different types of loops). It's a kind
> of subset of the more general procedural programming paradigm.
> 
>   I don't think the concept of "module" is part of the structured
> programming paradigm. A modular programming language may follow the
> principles of structured programming (and make its own additions), but
> that doesn't mean it's the same in the other way. And I don't think
> there's any requirement for a modular language to use structured programming
> principles (in the same way as an OOP language doesn't necessarily have
> to follow procedural programming principles).

My take on it is that BASIC [the *original* language] was an 
unstructured language - the entire program is basically a vast list of 
mostly sequential commands. And then we have Pascal, which is a 
structured programming language. It has user-defined data structures, 
subroutines and local variables. Things are more "structured".

As to whether modularity is orthogonal or not... I hadn't really thought 
about it.

>> (Actually, I've heard legend of another functional language where 
>> apparently modules *do* have inheritance... There are often debates 
>> about whether Haskell should do this - with most people agreeing the 
>> vast increase in complexity isn't worth it.)
> 
>   I have never understood why adding *optional* features, which you are
> in no way forced to use, to something would make it "too complex".

Well, take multiple inheritance for example. If your language supports 
multiple inheritance, it can't support using the "super" keyword, 
because it could refer to several different classes. (With single 
inheritance, it is obviously quite unambiguous.) So even if you never 
ever actually use MI, if the language your using supports it, it stops 
you from being able to have a super keyword to use. You'll have to refer 
to superclasses some other way.

It's a minor increase in complexity, but it's an example of how even if 
you don't use a particular feature, if it's available the language 
design has to cope with it.

>> [Obviously I meant "does Pascal count as modular?"]
> 
>   I don't know enough about Pascal to answer that question. (Is there
> a "standard" Pascal language anyways? I have the impression that each
> compiler company has created their own variant of Pascal, and that there's
> no official standard. I may perfectly be wrong, of course.)

Well, there are many dialects of BASIC. [And I'm not talking about VB, 
I'm talking about the *real*, unstructured BASIC.] Each one has its own 
little quirks, but you can still make general statements about BASIC 
overall.

>> Dynamic binding? Sure. That's the entire purpose.
> 
>> Inheritance? Mmm, not really, no.
> 
>   That's a bit contradictory given that dynamic binding (or its
> alternative, delegation) is inherently related to inheritance.

Dynamic binding just means choosing between several possible method 
implementation at runtime rather than compile time depending on the type 
of a particular value. You don't actually need inheritance for that.

[For example, in Haskell the "+" function has several implementations - 
for integers, doubles, ratios, and any user-defined types you care to 
add. When you add two values, it needs to pick the correct one. Often 
this can be done at compile-time, if the types are known. Otherwise it 
must happen at runtime...]

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

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Well, take multiple inheritance for example. If your language supports 
> multiple inheritance, it can't support using the "super" keyword, 
> because it could refer to several different classes. (With single 
> inheritance, it is obviously quite unambiguous.) So even if you never 
> ever actually use MI, if the language your using supports it, it stops 
> you from being able to have a super keyword to use. You'll have to refer 
> to superclasses some other way.

  The solution is rather simple: One of the base classes is the "super"
class, the rest aren't. (This can be differentiated with keywords when
inheriting, or even by the order in which the inheritance list is
specified: The first base class mentioned can be the "super" class.)

  Think of it as the rest of the base classes being interfaces with
support for member variables and function implementations.

-- 
                                                          - Warp

Post a reply to this message

> I thought that was structured programming?

Structured programming is if/while/for and functions/methods/whatever 
instead of goto.

Post a reply to this message

Orchid XP v7 wrote:
> If you consider "modular" to be a programming paradigm 

It is. Note that it has been superceded, but at the time the term was 
coined, it was quite a revolutionary idea.

> (Does Pascal count as "module" too?)

No.  :-)  One of the fundamental features of modules is information 
hiding. You can't hide the types in a Pascal program.  At least, not 
standard pascal.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Warp wrote:
>   I have never understood why adding *optional* features, which you are
> in no way forced to use, to something would make it "too complex".

Because you still have to learn these features to understand code that 
someone else has written.

Using the C preprocessor is optional in C. Yet if you don't know how it 
works, you're unable to read 99.44% of all the C code out there.

>> [Obviously I meant "does Pascal count as modular?"]
> 
>   I don't know enough about Pascal to answer that question. (Is there
> a "standard" Pascal language anyways? I have the impression that each
> compiler company has created their own variant of Pascal, and that there's
> no official standard. I may perfectly be wrong, of course.)

There's an official standard, but it was too weak (no modularity, no way 
of (for example) opening a named file, etc) to be useful for work on 
desktop type machines. Worked great on mainframes where you had the JCL 
set up to do stuff like open the files for you.

>> Dynamic binding? Sure. That's the entire purpose.
>> Inheritance? Mmm, not really, no.

>   That's a bit contradictory given that dynamic binding (or its
> alternative, delegation) is inherently related to inheritance.

Not really. Javascript has no inheritance but has dynamic binding. 
Anything with "duck typing" could be said to have dynamic binding 
without requiring inheritance.


-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message