Re: "ocaml_beginners"::[] Learning camlp4

On Monday 21 May 2007 14:19:44 dmitry grebeniuk wrote:
> Shalom, Jon.
>;
> >> In revised syntax if I write "value x = 23;" I sure that
>; >> I can never add " in ..." at the end and this binding won't
> >> be hidden by construction like
>; >> "let x = 23 in x + 7".
>
>; JH> This is a bad idea, IMHO. OCaml has no notion of
> JH> "global" scope, just a progression from outer to levels
> JH> of nested scope.
>
> It has global scope. Every value that should be visible
> to other modules should be declared in "global" scope (in
> "top level";).
> let () = let n = 1000 in <expr&gt; declares nothing and
> can't be exported.
> let n = 1000
>; let () = <expr&gt;
> declares n as top-level value and makes some side-effect.
> Both n and <expr&gt; will be evaluated.
> So keyword "value" is here especially to note what will be
> evaluated at program's run and what can be exported from
>; this module.

Counterexample:

module A : sig end = struct let x = 2 end;;

> And one more thing: when I see
> value x = <expr&gt;;
> I know I can refer to value x anywhere after its
> declaration.

Not true (see above).

> JH> F# has a better "#light" syntax that uses indentation to
> JH> replace the "in&quot; keyword, allowing you to move code with
>; JH> adding or replacing keywords:
>
&gt; The use of indentation as the part of language is a bit of
> perversion, I think. It requires IDE to write code without
> too much pain.

IDE should be essential. Look at Mathematica.

>; JH> That is not true. Currying of functions and functors
> JH> delays evaluation arbitrarily but the simplest
> JH> counter-example is the (very common):
>
>; Yes, but the difference between
> value () = ...
> and
> value f x = ...
> can be seen easily.
>
> JH> Superfluous parentheses.
>
> JH> More superfluous parentheses.
>
> Parentheses help programmer...

Unnecessary syntax gets in the way, IMHO.

> JH> OCaml offers incredible brevity precisely because these
&gt; JH> constructs are not closed:
>
> I prefer disambiguity to brevity.

There is no ambiguity, only precedence.

> JH> Again, this is improves the language for smart people
&gt; JH> who know precedence.
>
> Some other smart people prefer not to think about extra
&gt; details when compiler can think for them much better.

I think this sentance sums things up.

> >> I think it's good to have strong distinction between
> >> type t = C of t1 * t2
> >> and
> >> type t = C of (t1 * t2)
>
> JH> I think it would be better to optimise this away
>; JH> transparently.
>
> Extra complexity.

In the compiler. Less complexity in the language.

> For example, think about
> "Some (1, 2)" as a value of type "option 'a". There
&gt; should be code that will understand that "if block has
> length more than 1, then this is a tuple";. And code like
>; match opt_val with [None -> .. | Some x -> x]
> will be much more slower when it will be constructing value
&gt; "x&quot;.

Yes.

&gt; Constructor's arity and type of constructor's argument
> should not interfere because of polymorphism.

Then we agree.

> >> The ``else'' is mandatory in the ``if'' statement:
> >>
> >> OCaml Revised
> >> if a then b if a then b else ()
>
> JH> More unnecessary verbosity.
>
&gt; But there won't appear type error when ocaml adds
>; implicit "else ()".
> This "else ()" is useful when you write imperative code.

I get along just fine writing imperative code without it. So do the other 99%
of OCamlers.

> In my practice there were much more cases when I wrote
&gt; functional code and "else ()" tried to force the type of
> "then"-expression to unit. When there are many mutually
> recursive functions, it's hard to catch missing else.

I've never had this problem, though I can believe it exists. If so, better
error messages to help newbies would be better than butchering the language
for experts.

> JH> I completely disagree. The revised syntax is very old
> JH> and is deliberately not used by the majority of OCaml
&gt; JH> programmers because it simply isn't significantly
> JH> better. I don't know of a single significant project
> JH> that uses the revised syntax outside of camlp4. Indeed,
> JH> there is even a project to allow you to use ordinary
> JH> syntax inside camlp4.
>
> Classical "appeal to authority&quot;: "majority", "significant
&gt; project&quot;.
> Most of people use C/C++/Java/C# and most of software
> (for now) is written in these languages, so will I say that
>; these languages are better than others?

You should take this into account. I appreciate that you want to improve the
syntax of OCaml. Many people have tried before and some succeeded, but if
nobody uses their work what was the point?

To put it another way, there are far more important things to be discussing,
like operator overloading.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Jon Harrop wrote:
&gt; On Monday 21 May 2007 14:19:44 dmitry grebeniuk wrote:
&gt;> Shalom, Jon.
>;>
snip
>
> To put it another way, there are far more important things to be discussing,
> like operator overloading.
>

Now that we at it, wouldn't recursion also be an important issue
(standard and in modules)?

Messages in this topic (0) Reply (via web post) | Start a new topic

.

Shalom, Jon.

>> So keyword "value" is here especially to note what will be
>> evaluated at program's run and what can be exported from
>> this module.

JH> Counterexample:

JH> module A : sig end = struct let x = 2 end;;

"what _can_ be exported&quot;, but not "what _is_ exported&quot;.
In other words, if I see in revised syntax expression
that starts with "let&quot;, I know I can't export it to other
modules, and if I see "value .. = ..", I know I can export
it (if it is not "value () = .." or similar).

And don't you agree that "let .. = .." and
&quot;let .. = .. in <expr&gt;" are different by its nature?
First one define structure item, while the second one define
binding which can be used only in following <expr&gt;.

&gt;> The use of indentation as the part of language is a bit of
>> perversion, I think. It requires IDE to write code without
>> too much pain.

JH> IDE should be essential. Look at Mathematica.

I don't like such approach. It works good for
experimenting with language and for small programs, but not
for writing something big.
And it's impossible to use classic preprocessors (even
cpp) for indented code.

>> JH> OCaml offers incredible brevity precisely because these
>> JH> constructs are not closed:
>> I prefer disambiguity to brevity.
JH> There is no ambiguity, only precedence.

When a man who doen't know language sees the source first
time, it's better when he sees precedence of complex
constructions by his eyes rather than reads manual searching
for precedence. Complex constructions are, for example,
do, match and try-with, which are bracketed in revised syntax.

>> JH> Again, this is improves the language for smart people
>> JH> who know precedence.
>> Some other smart people prefer not to think about extra
>> details when compiler can think for them much better.
JH> I think this sentance sums things up.

Yes. For now, I've got rid of thinking about manual memory
management, runtime typing, NULL pointers. Next step --
stopping to think about precedence when it is not obvious.
For example, precedence in mathematical expression "13;2*3"
is obvious (it comes from math), but precedence in ocaml
expression "1 + 2 :: 3" is not (for me). And I don't want
to remember "superfluous precedences".

>>; >> I think it's good to have strong distinction between
>> >> type t = C of t1 * t2
>> >> and
>> >> type t = C of (t1 * t2)
>> JH> I think it would be better to optimise this away
>> JH> transparently.
>> Extra complexity.
JH> In the compiler. Less complexity in the language.

Compiler is already complex enough (there are bugs found
after most of releases).

>&gt; For example, think about
>> "Some (1, 2)" as a value of type "option 'a". There
>> should be code that will understand that "if block has
>> length more than 1, then this is a tuple";. And code like
>> match opt_val with [None -> .. | Some x -> x]
>> will be much more slower when it will be constructing value
>> "x&quot;.
JH&gt; Yes.

I don't want the compiler to slow down such simple matches.
Current behaviour of sum types is fine for me.
As fine as distinction between
value func x y z = ...
and
value func (x, y, z) = ...

&gt;> In my practice there were much more cases when I wrote
>> functional code and "else ()" tried to force the type of
>> "then"-expression to unit. When there are many mutually
>> recursive functions, it's hard to catch missing else.
JH> I've never had this problem, though I can believe it
JH>; exists. If so, better error messages to help newbies
JH> would be better than butchering the language for
JH&gt; experts.

There could not be any better error message in the code
like this:

let rec f x =
..
if ..
then g x
and g x =
..

So, here the type of (g x) is assumed to be unit. Normal
type inference.

>> JH> I completely disagree. The revised syntax is very old
>> JH> and is deliberately not used by the majority of OCaml
>> JH> programmers because it simply isn't significantly
>> JH> better. I don't know of a single significant project
>> JH> that uses the revised syntax outside of camlp4. Indeed,
>> JH> there is even a project to allow you to use ordinary
>> JH> syntax inside camlp4.
>> Classical "appeal to authority&quot;: "majority", "significant
>> project&quot;.
>> Most of people use C/C++/Java/C# and most of software
>> (for now) is written in these languages, so will I say that
>> these languages are better than others?
JH> You should take this into account. I appreciate that you
JH&gt; want to improve the syntax of OCaml. Many people have
JH&gt; tried before and some succeeded, but if nobody uses
JH&gt; their work what was the point?

New languages appear sometimes. People begin to use new
language (or new syntax) when they see that it is better
than alternatives (for their tasks). For new syntax the gap
is closer: new syntax can be used when there are automatic
converter available.

JH>; To put it another way, there are far more important
JH> things to be discussing, like operator overloading.

IIRC, Hindley-Milner typing is not decidable with
overloading. OCaml team prefer theory-approved solutions.

--
WBR,
dmitry mailto: gds-mlsts%40moldavcable.com">gds-mlstsmoldavcable.com

Messages in this topic (0) Reply (via web post) | Start a new topic

.