intelligence is a search for satisfaction

Donn Cave wrote:
>
> match k with
> 0) -> Printf "k 0\n"; True
> 1) -> Printf "k 1\n"; False
>
> Now, is that the same as
>
> (
> match k with
> 0) -> Printf "k 0\n"; True
> 1) -> Printf "k 1\n"; False
> )

Sure it is the same. Those parentheses don't eliminate this ambiguity.
You probably meant something like this:

match k with
0) -> Printf "k 0\n"; True
1) -> (Printf "k 1\n"; False)

Anyway, the ambiguity is there, and I have been bitten by it. Luckily,
it was a minor injury

Have you tried the revised syntax? It doesn't have such problems.

> The ocaml compiler is very good as far as I'm concerned, really
> emphatically the best by far of any functional language I have
> tried to use, so it's too bad Objective CAML is not more appealing.

Sometimes I think that it's just because of compromises Ocaml developers
made. I mean the unboxed int hack, imperative strings, imperative
arrays, imperative hashes. If you really want to program in a purely
functional style with it, performance can be less impressive.

> I've wondered if there couldn't be some way to build a different
> language on ocaml, something like Haskell with a native string
> type like Python's (not like Objective CAML)

Adding support for efficient strings to Haskell is quite high on
my wish/TODO list. There is PackedString but it lacks some important
operations, like efficiently reading a line from a Handle directly to a
PackedString.

Best regards,
Tom

--
..signature: Too many levels of symbolic links
 >> Stay informed about: intelligence is a search for satisfaction 

Donn Cave wrote:

> I don't know. I would have to write a test program. I think
> it's the first, because I recall that explicit block notation
> at the bottom level doesn't change a thing,

I tried the second one and it was incorrectly typed, so it may be the
first (below).

# let _ =
let k = 0 in
let x =
(
match k with
0 -> (); true
| 1 -> (); false
)
in x;;
Characters 38-105:
Warning: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
2
....(
match k with
0 -> (); true
| 1 -> (); false
)
- : bool = true


> 1) -> BEGIN Printf "k 1\n" END;
> False -- same story, it's really part of 1) -> {}

I don't really understand the problem. Is the problem that (a; b) is
equivalent to a; b? Or that begin ... end is not of type unit? Or that
in a; b, the type of a and the type of b need not be the same?


> Not everyone thinks this is a serious problem, maybe only myself,
> but I think it's enough to qualify Objective CAML for seriously
> broken syntax.

I don't understand what the problem is so i can't comment on it, but the
fact integers are 31 bit integers because of the design of the
implementation isn't particuarly nice. It's better imo not to let
implementation issues pollute the language as much as possible.

The people behind O'Caml did it for a reason, although it's not clear to
me what the reason was.


Chris
 >> Stay informed about: intelligence is a search for satisfaction 

["Followup-To:" header set to comp.lang.functional.]
chris wrote:
> I don't understand what the problem is so i can't comment on it, but the
> fact integers are 31 bit integers because of the design of the
> implementation isn't particuarly nice. It's better imo not to let
> implementation issues pollute the language as much as possible.
>
> The people behind O'Caml did it for a reason, although it's not clear to
> me what the reason was.

I think it was efficiency and simplicity of implementation. I don't like
the result.

Best regards,
Tom

--
..signature: Too many levels of symbolic links
 >> Stay informed about: intelligence is a search for satisfaction 

Brandon J. Van Every on Tue, 10 Aug 2004 14:06:30 -0700 writes:

> cr88192 wrote:
>>
>> ok.
>> the bsd liscence is pretty cool imo...
>> similar would likely go for the mit liscence.
>>
>> in your oppinion, how does lgpl compare?
>
> The difficulty with the LGPL is that in commercial practice, you must
> provide your library as a dynamic link library to comply with the license.
> You can't, for instance, just compile the library statically into your code.
> I find this to be an annoying futz factor, and in some commercial contexts
> the restriction would be unacceptable. Of course that's the LGPL's point,
> it wants to make certain things unacceptable to commercial development.
> LGPL prioritizes the right of some geek to fiddle with the library as he
> sees fit.

That's not correct.

You _can_ statically link proprietary code with LGPL licensed code,
for example by providing the (linkable) object file(s) for the
proprietary code.

This is to allow the use of newer versions of the LGPL library
(perhaps containing bug-fixes, improvements, etc...).

From the LGPL [1], "Preable":

<< ...

When a program is linked with a library, whether statically or
using a shared library, the combination of the two is legally
speaking a combined work, a derivative of the original library. The
ordinary General Public License therefore permits such linking only
if the entire combination fits its criteria of freedom. The Lesser
General Public License permits more lax criteria for linking other
code with the library.

... >>

1. http://www.gnu.org/licenses/lgpl.html

Now, "TERMS AND CONDITIONS ...", section 6a and section 6c:

<< ... Also, you must do one of these things:

* a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable
linked with the Library, with the complete machine-readable
"work that uses the Library", as object code and/or source code,
so that the user can modify the Library and then relink to
produce a modified executable containing the modified
Library. (It is understood that the user who changes the
contents of definitions files in the Library will not
necessarily be able to recompile the application to use the
modified definitions.)

...

c) Accompany the work with a written offer, valid for at least
three years, to give the same user the materials specified in
Subsection 6a, above, for a charge no more than the cost of
performing this distribution.

...>>

> MIT / BSD doesn't prioritize anybody. You can do whatever you want with the
> code. Nothing is in the way. I figure, if you're going to give something
> away, give it away completely. If it's too valuable to give away
> completely, don't! Keep that chunk proprietary.

Yeah, BSD-like licenses shares with everyone, GPL shares only with who
share, the LGPL shares with everyone, but less than the BSD-alikes.

Some peoples refer to BSD-like licenses as permissive licenses, and to
GPL and LGPL licenses as copyleft licenses.

Some text about Copyleft:

2. http://www.gnu.org/licenses/licenses.html#WhatIsCopyleft

3. http://www.gnu.org/philosophy/why-copyleft.html

4. http://www.gnu.org/philosophy/pragmatic.html

--
Marco Parrone <marc0.RemoveThis@autistici.org> [0x45070AD6]
 >> Stay informed about: intelligence is a search for satisfaction 

Marco Parrone wrote:
> Brandon J. Van Every on Tue, 10 Aug 2004 14:06:30 -0700 writes:
>>
>> The difficulty with the LGPL is that in commercial practice, you must
>> provide your library as a dynamic link library to comply with the
>> license. You can't, for instance, just compile the library
>> statically into your code. I find this to be an annoying futz
>> factor, and in some commercial contexts the restriction would be
>> unacceptable. Of course that's the LGPL's point, it wants to make
>> certain things unacceptable to commercial development. LGPL
>> prioritizes the right of some geek to fiddle with the library as he
>> sees fit.
>
> That's not correct.
>
> You _can_ statically link proprietary code with LGPL licensed code,
> for example by providing the (linkable) object file(s) for the
> proprietary code.

I said "in commercial practice." No proprietary developer wants to provide
what you suggest.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 >> Stay informed about: intelligence is a search for satisfaction 

Followup-To: comp.lang.functional

On Tue, 10 Aug 2004 20:17:26 +0000, chris wrote:

> I don't understand what the problem is so i can't comment on it, but the
> fact integers are 31 bit integers because of the design of the
> implementation isn't particuarly nice. It's better imo not to let
> implementation issues pollute the language as much as possible.

A reasonable idea is to represent small integers in 31 bits, larger
integers as bignums, and do this transparently to the user. This is what
various implementations of Lisp and Scheme do.

Glasgow Haskell also uses two internal representations of type Integer,
but the small case, and the type Int as a whole, use full machine word.
It's a full word because in the general case the int must be boxed anyway
(because of laziness). The compiler makes a sophisticated analysis which
allows it to be often unboxed.

Such analysis would probably be a bad tradeoff for OCaml, because it would
introduce some boxing and unboxing which is less efficient than using the
invariant representation of tagged ints directly, would introduce much
complication for internals of the compiler and runtime, and there are no
other reasons than interfacing to some libraries to make ints 32 bits
instead of 31 bits.

> The people behind O'Caml did it for a reason, although it's not clear to
> me what the reason was.

For performance.

31-bit ints are faster than a hybrid of 31-ints and bignums, especially
if they ignore overflow like in OCaml (as opposed to SML).

They are also faster than 32-bit ints in a language with parametric
polymorphism, unless the compiler performs sophisticated analysis and/or
give up some language properties to compile polymorphic code separately
for different types, like C++ and new C# do. C++ gives up separate
compilation of templates, and C# relies on generating code at runtime.

--
__("< Marcin Kowalczyk
\__/ qrczak.DeleteThis@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
 >> Stay informed about: intelligence is a search for satisfaction 

On Tue, 10 Aug 2004 10:41:53 -0700, Donn Cave wrote:

>> OCaml's syntax is baroque, but not as bad as C++.
>
> It's worse. C++ may have a lot of keywords and confusing semantics,
> but at the basic level of writing out expressions and having what
> you wrote turn out to be what you meant, the syntactic structure is
> not a big problem.

I know no language which is harder to parse than C++.

It has all phases of compiler frontend entangled. In most languages after
parsing comes name resolution, then typechecking if the language is
statically typed, then optimizations.

But in C++ the result of constant expressions may influence template
specializations, which influence types, which influence name lookup,
which influence parsing of declarations. Of course forward dependencies
between these phases are still there, so all those phases must be
interleaved, together with template instantiation.

This implies that it's impossible to write an accurate parser of C++ which
e.g. is able to see which names are declared in a particular declaration,
without doing a complete typechecking, Koenig lookup, resolving inherited
names, function template argument deduction, user type conversions, and
constant folding of integer expressions.

A silly example:

template<bool> struct A {};
template<> struct A<true> {static int x;};
template<> struct A<false> {typedef int x;};
int p, x;
void f() {
A<sizeof(int)<4>: * p;
// Whether the above line uses the global p, or declares a local p
// as a pointer, depends on the size of int.
}

BTW, the line
A<sizeof(int)<4>: * p;
would have a completely different meaning if A were an int variable
rather than a class template. It would compare A with sizeof(int),
compare the result with 4, and compare the result with the value of
global x multiplied by p.

Beware of cases like this:
template <class T>
void f() {
T::A<sizeof(int)<4>: *p;
}
This does not define p as a pointer even if A is a template inside every
class T this function is instantiated for. It does the comparison version,
because C++ wants to parse a template without yet knowing what T will
contain, and it assumes the "it's not a type and not a template" version.
This must be written thus instead:
template <class T>
void f() {
typename T::template A<sizeof(int)<4>: *p;
}

Be sure to insert "typename" and "template" disambiguation markers only in
templates. Outside templates this kind of ambiguity can't happen and C++
doesn't *allow* to add these disambiguation markers there.

So much for C++ grammar simplicity.

--
__("< Marcin Kowalczyk
\__/ qrczak.TakeThisOut@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
 >> Stay informed about: intelligence is a search for satisfaction 

On Wed, 11 Aug 2004, Peter Ashford wrote:

> Philippa Cowderoy wrote:
> > 3) Higher-order functions make it easier to build up code at run-time.
> >
> > 4) Techniques such as monads and monad transformers make it even easier -
> > you can build the semantics of your DSL piece-by-piece.
>
> Could you give an example?
>

A fun one's the List monad - it represents computations that can return
zero or more results, instead of functions that always return one
result[1]. Makes it easy to write code that maintains a list of
possibilities and filters them down, for example - but more interestingly,
if you only want one result then under lazy evaluation it's equivalent to
backtracking.

Supposing you want to bolt exceptions on top of this, you could apply the
ErrorT monad transformer to it. Alternatively, you could apply a ListT
transformer to the Error monad - these produce two different results.
ErrorT on top of List yields a semantics where an exception appears within
the list of possible results and can be caught appropriately, whereas
ListT on top of Error produces a system where an exception stops the whole
computation.

Prolog, anyone?

> > 5) The type systems are more suited to this kind of work.
> >
>
> I really must get around to playing more with OCaml. I really love LISP
> but that's as far as I've ever gone with Functional Languages (except
> for dabbling briefly with Erlang) and I have to say the 'hard core'
> functional languages freak me out somewhat ) I just don't get them.
> Which is all the more reason to put the effort in a learn one properly )
>

Any idea what bugs you? It's a bit weird working without state at first,
certainly. Well, until you find all the tricks for providing state when
you really really need it (gee, I'm talking a stateful protocol over the
network here...).

If you decide to learn Haskell, you might find these two links useful:
http://www.haskell.org/tutorial/ (general tutorial)
http://www.nomaware.com/monads/html/ (a decent tutorial on monads)

I'm afraid somebody else'll have to provide equivalent links for OCaml,
I've not really used it any.

[1] Monads effectively provide means to embed a semantics that's
higher-order[2] into Haskell, and Haskell within that semantics. There's
an Identity monad that represents Haskell semantics on top of which you can
apply monad transformers, for example. A more generic framework called
Arrows relaxes the higher-order restriction.

[2] By which I mean that computations can take computations as
parameters and return computations as results - if there's an existing
use of the term that differs from this, could somebody enlighten me
btw? - this has a consequence, which is that any data the monad keeps
(state being the classical example) won't branch any - this allows the IO
monad to represent a function of type world->world without ever trying to
duplicate the world, thus allowing a pure (if not complete) language to
express interaction with the outside world without giving too many
physicists big headaches.

--
flippa.TakeThisOut@flippac.org
 >> Stay informed about: intelligence is a search for satisfaction 

In article <2nribhF3pupgU1.RemoveThis@uni-berlin.de>, "Brandon J. Van Every" <try_vanevery_at_mycompanyname.RemoveThis@yahoo.com> wrote:
>The other upcoming paradigm shift that I think will be incredibly important
>is fullblown voice recognition and voice synthesis. If we get to the point
>where we can *talk* to our computers with 100% accuracy, that's going to
>change commerce fundamentally.

Personally, I seriously doubt voice recognition will catch on. HR
people or accountants will never use it because their data is often
semi-confidential. Programmers aren't likely to use it, at least in
the near term, because of all the punctuation needed.
Managers need primarily to interact with other people and don't
produce loads of output streams, apart from email, which again is
likely to be semi-confidential. Have you ever worked in an office
where someone played a radio tuned to a station you don't like?
Multiply that by five or ten.

Novelists, maybe, would find it useful.

Alan
 >> Stay informed about: intelligence is a search for satisfaction 

Philippa Cowderoy wrote:

> On Tue, 10 Aug 2004, Peter Ashford wrote:
>
>
>>In what way does OCaml eclipse that kind of tool creation ability that
>>you get from OO languages?
>>
>
>
> I'll answer for Haskell, as I don't use ML much, but some of the points
> still stand:
>
> 1) There are excellent parsing tools available - in particular, this seems
> to be where Spirit got its inspiration from
>
> 2) The pattern-matching facilities, which operate on any data type. They
> make mildly complicated transformations on trees and graphs an absolute
> doddle.

Okay, that'll explain the language creation benefits that Brandon was
talking about,

> 3) Higher-order functions make it easier to build up code at run-time.
>
> 4) Techniques such as monads and monad transformers make it even easier -
> you can build the semantics of your DSL piece-by-piece.

Could you give an example?

> 5) The type systems are more suited to this kind of work.
>

I really must get around to playing more with OCaml. I really love LISP
but that's as far as I've ever gone with Functional Languages (except
for dabbling briefly with Erlang) and I have to say the 'hard core'
functional languages freak me out somewhat ) I just don't get them.
Which is all the more reason to put the effort in a learn one properly )
 >> Stay informed about: intelligence is a search for satisfaction 

Peter Ashford wrote:
>
> I really must get around to playing more with OCaml. I really love
> LISP but that's as far as I've ever gone with Functional Languages
> (except
> for dabbling briefly with Erlang) and I have to say the 'hard core'
> functional languages freak me out somewhat ) I just don't get them.
> Which is all the more reason to put the effort in a learn one
> properly )

In a hand-wavy sort of way, I think functional languages are easiest to
understand as "having far better templating capabilities than C++ has."
That's all the functional paradigm really seems to amount to.

Sure, there's this fixation on copying stuff rather than modifying state,
but practical languages like OCaml blow that off. Anally copying everything
is a purist notion, borne of the idea that this is going to make theorem
proving easier.

There may be a point to that, but it sounds remarkably like the argument "if
everybody would just do everything in terms of RISC, the world will be such
a better place!" Well, the best RISC CPU in the world (the DEC Alpha)
couldn't solve lotsa marketing problems in practice, nor emulate Intel's
architectural approach particularly well. The main schism was how one
accesses memory. RISC architectures are deeply pipelined and want a LOAD,
COMPUTE, STORE coding style. Intel would access memory willy nilly.
Actually, hm, it's kinda the same semantic issue as the FP guys complain
about, having to deal with state changes when you don't want to.

Anyways, as great a CPU as the DEC Alpha was, it wasn't coupled with an
equally good memory controller. Thus it didn't perform as well as it could
have. So although RISC has been influential, it simply doesn't solve all of
the industrial problems or make the world a fundamentally better place.
That's what I think the Pure FP fixation on copying amounts to.
Realistically, this just ain't gonna have significant industrial impact.

--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.
 >> Stay informed about: intelligence is a search for satisfaction 

>
> Well, maybe both C++ and Ocaml have this property. My own view is that
> designing and programming games is hard, and so long as your language is
> powerful, scales well, and is not too awful, it's not the problem. Of
> course you think C++ is too awful - I'm happy to stick with it.

That's my point of view as well (of course, insert Java for C++ ) )

I don't often find myself with programming issues which I can figure out
how fix but can't really express cleanly with the language I'm using. I
suppose that's part of the reason I'm a little dubious about the
advantages of using a functional language.

<uninformed opinion>
FL's seem to have lots of benefits that seem very high level and obscure
whereas the problems I end up solving usually don't seem to require
especially complex or unusal programming approaches to defeat. The real
work is figuring out what I want to do and a good algorithm to do it
rather than wrangling with the language.
</uninformed opinion>
 >> Stay informed about: intelligence is a search for satisfaction 

In article <2nsr9uF4dvqjU1 RemoveThis @uni-berlin.de>,
try_vanevery_at_mycompanyname RemoveThis @yahoo.com says...
> Donn Cave wrote:

> > It's worse. C++ may have a lot of keywords and confusing semantics,
> > but at the basic level of writing out expressions and having what
> > you wrote turn out to be what you meant, the syntactic structure is
> > not a big problem.
>
> How many multiply inherited virtual base classes with pointers have you
> done?

0.

>You're right that C++ has the readability advantage for small code
> blocks, but once you scale up, all of C++'s picky problems rear their ugly
> hydra heads!

I recommend scaling up software, instead of scaling up language
complexities!

- Gerry Quinn
 >> Stay informed about: intelligence is a search for satisfaction