Container library progress

[jacob navia]

Gareth Owen a écrit :

I'm sorry, but I don't understand this.

What can be a method that is common to ALL containers, serial, associative or
whatever?

Spilling.

ANY container can spill its contents into a sink, i.e. in data processing
terms, write a serialized representation of its contents into a character
string buffer or into a file stream.

This can be done with the "Apply" function, that would call a user defined
"Print" function or "WriteToDisk" function to write the contents of the
container into the disk.

 

[Nick Keighley]

Gareth Owen a écrit :

I understand but I don't agree!

What can be a method that is common to ALL containers, serial, associative or
whatever?

Spilling.

function application

ANY container can spill its contents into a sink, i.e. in data processing
terms, write a serialized representation of its contents into a character
string buffer or into a file stream.

This can be done with the "Apply" function, that would call a user defined
"Print" function or "WriteToDisk" function to write the contents of the
container into the disk.

yes, but the apply functions doesn't have to be a serializer. You
could increment all the elements for instance. This isn't just nik-
pikery. The point about serialization is that implies an ordering
whilst function application doesn't neceessarily.

The functional programming people sometimes have both a map() (apply a
function to all elements- no ordering) and for_each() apply a function
to each element in order.

 

[Nick Keighley]

On Nov 11, 9:36 am, Nick Keighley <[email protected]>

Erm... Good question.  I don't really have a firm handle on what
polymorphic means applied to operators.

"Operator" is a posh word for "function". The syntax may be different,
but the idea is the same. It is not difficult to envisage a C-like
language where all the operators are replaced by functions (with the
possible exception of the function call operator!).[/QUOTE]

be careful you might reinvent Lisp...

[my examples are from the Lisp-like language scheme]

There there are no operators just some functions a spelt funny

(average 1 2 3)
(+ 1 2 3)

the "function call operator" is called apply

(apply + (1 2 3))

[I know I missed a quote out]

Obviously,
functions like add() would have to be implemented (at least
initially) in a language-external way. Er, actually that's not quite
true, is it?

there has to be a set of built in primitives. This set can be
surprisingly small.

 

[jacob navia]

Nick Keighley a écrit :

I understand but I don't agree!



function application

Yes, since spilling needs function application. But function application
is done with a purpose, and the common purpose for all containers that
I proposed was spilling the contents into a sink.

yes, but the apply functions doesn't have to be a serializer. You
could increment all the elements for instance. This isn't just nik-
pikery. The point about serialization is that implies an ordering
whilst function application doesn't neceessarily.

Serialization doesn't imply an order. When the container is an
associative container there is no fixed order.

The functional programming people sometimes have both a map() (apply a
function to all elements- no ordering) and for_each() apply a function
to each element in order.

In the case of associative containers, Apply is equivalent to map (no order)
but in the case of sequential containers Apply will follow the sequence order.

 

[Nick Keighley]

It's never been clear to me why many languages let you extend the
existing operators in completely random directions, but don't let you
add to them.

if you want Algol-68 you know where to find it (Algol-68 allowed you
to define new operators and even specify their precedence)

 

[Nick Keighley]

What I said:

You can do OO programming in C. There is no language support, and you
are not constrained to do OO programming within a fixed language framework.

you make the lack of support sound like a virtue...

You can do as you want, classify as you want, you are completely free to do as you
think it is best for your application.

C is Turing Complete. We can do anything in C.

What Nick Keighley understood :

was i mistaken?

Mr Keighley thinks using this kind of language is funny, and probably is very
proud of it.

well obviously I think my (I stole it actually) jokes are funny!

I don't think C makes OO very easy. I think your lack of inheritance
is telling. Though you could argue that don't need it in this
application.

We can do anything in C, but it isn't necessarily easy.

But what is important to understand is that all OO frameworks and most other
languages give you that: a FRAMEWORK where you should fit your ideas. This is
very good if your needs fit tightly in the framework.

and C is no different in this regard

In most cases, they don't and then... well then you find yourself

 > trying to shove half a a pound of melted butter up a
 > hedgehog's bottom with a red hot needle.

and it is your fault since you could have done it in C.

and why is C any different? If I want a Lisp style CLOS (it allows
dispatch on more than one argument- hence avoiding the dreaded Vistor
Pattern [*]) then I can write one in C++. Or Cobol. But is it worth
the trouble?


[*] it doesn't really matter what this all means, it just means CLOS
can do things easily that are hard to do even in C++'s object model

 

[jacob navia]

Nick Keighley a écrit :

you make the lack of support sound like a virtue...

Well, that *is* a virtue from my point of view, and that is what you don't understand.
Exactly the LACK of any paradigm that is the accepted paradigm for the language allows
you to design ANY paradigm yourself!

The advantage of C is precisely that it does NOT impose a pre-determined way of doing
things.

I don't think C makes OO very easy. I think your lack of inheritance
is telling. Though you could argue that don't need it in this
application.

Precisely. Anyway I could do some kind of inheritance. Just put common
methods and data in the same position in all containers and there,
you have inheritance.

We can do anything in C, but it isn't necessarily easy.

If you want easy OO programming do C# or C++ or...

[long list snipped for brevity]

If you want to program exactly the paradigm you think it is best for
your application use C.

and C is no different in this regard

What framework is imposed on you? None! That is precisely its advantage.

 

[Nick Keighley]

Nick Keighley a écrit :


Well, that *is* a virtue from my point of view, and that is what you don't understand.

I do understand. I don't agree. We are beginning to repeat ourselves
so I'll make this brief.

Exactly the LACK of any paradigm that is the accepted paradigm for the language allows
you to design ANY paradigm yourself!

great. So I'll rewrite all my applications in FORTRAN IV

*ALL* real-world programming languages are Turing Complete and hence
are in a theoretical sense equivalent to any other TC language. If I
want OO (or CLOS or functional programming) I can write a translator
in FORTRAN IV. Hence FORTRAN IV can be used to program in any
paradigm.

This is known as the Turing Tarpit, where anything is possible but
nothing is easy.

The advantage of C is precisely that it does NOT impose a pre-determined way of doing
things.

The advantage of <any language> is precisely that it does NOT impose a
pre-determined way of doing <certain> things.

<snip>

 

[gwowen]

If you want to program exactly the paradigm you think it is best for
your application use C.
What framework is imposed on you? None! That is precisely its advantage.

In what way does the availability of C++ STL containers *impose* a
framework on C++ programmers?
Do the same criticisms not apply to C-augmented-with-your-container-
library?

 

[bartc]

if you want Algol-68 you know where to find it (Algol-68 allowed you
to define new operators and even specify their precedence)

And then you might end up with APL or some equally succinct language.

Sometimes giving too much freedom to a mere programmer (rather than a
language designer or some other responsible person) is not a good idea...

 

[Nick Keighley]

And then you might end up with APL or some equally succinct language.

I think APL avoided precedence by always applying the operators in the
same order (right to left if I recall correctly)

Sometimes giving too much freedom to a mere programmer (rather than a
language designer or some other responsible person) is not a good idea...

I think that's why no one has followed Algol-68's example. But for
ages it allowed me to say "oh, <language X> is just a subset of
Algol-68"

 

[Ben Bacarisse]

I think that's why no one has followed Algol-68's example.

Except Pop-11, Haskell, ML (and derivatives like F# and OCaml),
Scala and, no doubt, others

<snip>

 

[Seebs]

What can be a method that is common to ALL containers, serial, associative or
whatever?

Count of stored members. Retrieval by key (where key may be an index or
some other kind of value). Addition of a new member with a given key.
Iteration over all members.

You might find it instructive to compare arrays and hashes in something like
Ruby, which treats them a fair bit like each other in some ways.

-s

 

[dragan]

The bitstring module is finished (modulo tests).

Who are you talking to?? Does this guy have an audience and marketing avenue
here?

 

[David Thompson]

be careful you might reinvent Lisp...

LISP et seq also make control structures (routine, if/selection,
loop/iteration, etc.) look like function calls (or vice versa).

An example of only operator=function is FORTH and PostScript. They do
all computation against an implicitly shared data stack (or perhaps
two), so you don't need 'apply', just 'execute'. PostScript has very
limited special syntax for control structures, plus more built on this
somewhat like LISP (~compile-time) macros; and normally uses names for
what are normally operators but you can define symbols. FORTH has
explicit and manipulable compilation into the dictionary, with a small
builtin set of control primitives to which you can add more; and
normally symbols for most operators but you can define names.

 

[Phil Carmody]

LISP et seq also make control structures (routine, if/selection,
loop/iteration, etc.) look like function calls (or vice versa).

I'dn't've said so. They make control structures look like
structured data, and they make function calls look like
structured data. There's no attempt to make either look
like the other, simply both to a common sexp structure.

Phil

 

[Richard Bos]

Bjarne Stroustrup (sp?) has written a few times on why you can't add
operators to C++, and the reasons given do eventually boil down to
"precedence issues will kill you."

He hasn't studied Prolog very well, then. It has no problems with
letting you define your own operators with your own desired precedence
(and binding).

Mind you, that doesn't mean that it's a good idea. All it means is that
precedence issues are not the reason why it's a bad idea.

Richard

 

[Ben Pfaff]

He hasn't studied Prolog very well, then. It has no problems with
letting you define your own operators with your own desired precedence
(and binding).

Smalltalk gets away with it, too, by having a very simple
precedence chart. Prefix unary operators have the highest
precedence, followed by binary operators, which always associate
left to right.

 

[robertwessel2]

He hasn't studied Prolog very well, then. It has no problems with
letting you define your own operators with your own desired precedence
(and binding).

Mind you, that doesn't mean that it's a good idea. All it means is that
precedence issues are not the reason why it's a bad idea.

While I've never done more than dabble in Prolog, and that probably 15
years ago, how does it handle that? You could either have a very
simple scheme (like Smalltalk's or other languages that essentially
have no precedence - Forth, Lisp, APL, etc.), or you have a problem,
as far as I can see.

Do you define precedence of the new operator globally or locally?
While defining it globally is fairly straight forward, it seems like
it would easily lead to conflicts as soon as more than one attempt was
made to define that operator. IOW, package A does "#defineop "-:-"
binary,precedence=3.5,bind=rtl" and package B does "#defineop "-:-"
unary,precedence=2,bind=ltr", and you've got a mess. Of course you
could simply define two incompatible definitions as being an error,
but then someone’s going to try to reinvent namespaces again.

OTOH, if you define them locally, you get parsing problems, in that
you can't determine the precedence or binding of an operator without
knowing the types it's operating on, and you can't determine that
before you know what operands are binding with the operator.

 

[Dik T. Winter]

>
> Smalltalk gets away with it, too, by having a very simple
> precedence chart.

Algol 68 had it too. Unary operators had highest priority, others got a
priority ranging from 9 to 1 (programmer defined). However, I think
Stroustrup alludes to the possible problem in Algol 68 where you could
*redefine* the priority of operators within a block. E.g. with the
predefined operators '+' and '*' the following block would print 65:

'begin' 'prio' '*' = 6, '+' = 7;
print(5 * 6 + 7)
'end'

and all operators that looked the same would have the same priority at each
particular place.