if vs. when vs. and: style question

if vs. when vs. and: style question

[Marcin Borkowski]

Hi there,

assuming (e1) and (e2) are some expressions, all three forms:

(if (e1) (e2))

(when (e1) (e2))

(and (e1) (e2))

are semantically equivalent.  Which one is better style (and when)?
I would guess that =when= is better iff (e2) is a =progn= (since we can
drop the =progn= altogether, and this seems to be the point of =when=),
and =and= might be considered better (well, maybe) by some people when
both (e1) and (e2) are very short (though I personally would avoid that,
since =if= seems easier for a human to understand at a first glance).
Am I right?

Notice: by “better” I mean “more idiomatic”, or “easier/faster to read
for a human”, or “more likely to be used by an experienced Elisp
hacker”, etc.

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Hi there,
>
> assuming (e1) and (e2) are some expressions, all three forms:
>
> (if (e1) (e2))
>
> (when (e1) (e2))
>
> (and (e1) (e2))
>
> are semantically equivalent.  Which one is better style (and when)?
> I would guess that =when= is better iff (e2) is a =progn= (since we can
> drop the =progn= altogether, and this seems to be the point of =when=),
> and =and= might be considered better (well, maybe) by some people when
> both (e1) and (e2) are very short (though I personally would avoid that,
> since =if= seems easier for a human to understand at a first glance).
> Am I right?

In general, WHEN is better than IF.

Also, (unless (e1) (e2)) is better than (if (not (e1)) (e2)).

Notably, WHEN and UNLESS have an implicit progn:

   (when (e1)
     (e21)
     (e22)
     …
     (e2n))

I use IF only in ternary form:

  (if (etest)
    (ethen)
    (eelse))


AND is better when the result is boolean (and any result is always a
generalized boolean, right?).

I would use WHEN rather than AND in general, with a preference for WHEN
for procedural forms, and AND for resulting expressions:

   (defun get-it (key)
      (when (full-moon-p)
         (error "full moon"))
      (when (invalid-key-p key)
         (error "invalid key"))
      (and (exist-key-p key)
           (find-key key)))


Notably if you consider OR, it's quite idiomatic
to use it even for non-boolean (and notice that in CL, AND and OR return
multiple values too):

So you can typically have functions such as:

  (defun find-thingy (name)
    (or (find-thingy-in-whatcha name)
        (find-thingy-in-macall name)
        (find-thingy-in-it name)
        (error "not found")))

which is much more concise and clear than:

    (let ((thingy-found-in-whatcha (find-thingy-in-whatcha name)))
      (if thingy-found-in-whatcha
        thingy-found-in-whatcha
        (let ((thingy-found-in-macall (find-thingy-in-macall name)))
           (if thingy-found-in-macall
             thingy-found-in-macall
             (let ((thingy-found-in-it (find-thingy-in-macall name)))
               (if thingy-found-in-it
                 thingy-found-in-it
                 (error "not found")))))))

So much so that if I had to wrap those steps in other expressions, I
would write a macro similar to OR to do it and keep the find-thingy
function that simple.


So by analogy, using AND can be justified:

  (defun find-thingy (name)
    (and (valid-name-p name name)
         (exists-thingy-named name)
         (find-thing-or-create name)))

compared to the less concise:

  (defun find-thingy (name)
    (when (valid-name-p name name)
      (when (exists-thingy-named name)
         (find-thing-or-create name))))

or

  (defun find-thingy (name)
    (when (and (valid-name-p name name) 
               (exists-thingy-named name))
       (find-thing-or-create name)))


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

RE: if vs. when vs. and: style question

[Drew Adams]

>     (or (find-thingy-in-whatcha name)
>         (find-thingy-in-macall name)
>         (find-thingy-in-it name)
>         (error "not found")))
...
>     (and (valid-name-p name name)
>          (exists-thingy-named name)
>          (find-thing-or-create name)))

Yes, I do that too.  It is a case where the behavior of each
piece matters (can matter), even if it might not be the case
that the return _value_ is used.  It's about making use of the
behavior of `and' and `or'.

But I use `(unless a b)', not `(or a b)' if the code does not
use the resulting value and is thus just for the side effects
of `b'.  Likewise, I use `(when a b)', not `(and a b)', if the
value is unimportant.

RE: if vs. when vs. and: style question

[Drew Adams]

> assuming (e1) and (e2) are some expressions, all three forms:
> (if (e1) (e2))
> (when (e1) (e2))
> (and (e1) (e2))

Plus `cond', `unless', `or', and `not'.

> are semantically equivalent.  Which one is better style (and when)?
> I would guess that =when= is better iff (e2) is a =progn= (since we can
> drop the =progn= altogether, and this seems to be the point of =when=),
> and =and= might be considered better (well, maybe) by some people when
> both (e1) and (e2) are very short (though I personally would avoid that,
> since =if= seems easier for a human to understand at a first glance).
> Am I right?
> 
> Notice: by “better” I mean “more idiomatic”, or “easier/faster to read
> for a human”, or “more likely to be used by an experienced Elisp
> hacker”, etc.

FWIW -

I use a convention that you will find mentioned in "Common Lisp
The Language" (1 & 2):

I use `if', `and', and `or' when the return value is significant
(i.e., it is used; it makes a difference to the behavior).

I use `when' and `unless' _only_ when the return value is not
significant (not used).  IOW, they signify side effects only, when
I read them (in code I wrote).

---

Beyond that -

I use `cond' in both contexts (whether or not the return value is used).

I use `if' _only_ for the if-then-else case (3 args, not 2).  For the
if-then case (only two args) I use `and' or `or' (if the return value
is significant) or `when' or `unless' (if the return value is not used).

For `(if test nil val)' I typically use `(and (not test) val)'.
But sometimes I use (if test nil other-val), if I really want to point
out the nil return possibility (esp. if I want to put a comment on
its line).

Similarly, for `(if test val nil)' I typically use `(and test val)'.

I typically use `(cond (test foo1 foo2...) (t bar1 bar2...))' instead
of `(if test (progn foo1 foo2...) bar1 bar2...)'.

I typically use `(if test val sexp1 sexp2...)' instead of
`(cond (test val) (t sexp1 sexp2...))'.  But sometimes I don't. ;-)

And yes, I typically use a single `setq' for sequential assignments.
And that means that I can use `(if test (setq...) val)' instead of
`(if test (progn (setq...) (setq...)...) val)'.

Because I use a single `setq' for multiple assignments, seeing two
`setq's "next to" each other makes clear that they are at different
levels; they are not siblings.  E.g.

     (setq...))
    (setq...)

In a `setq' with multiple assignments (and in a `let' with multiple
bindings) I typically align the values too, not just the variables:

(setq toto    kelp
      bar     rhinoceros
      whoops  nematode)

---

I also use `()' instead of nil when it represents the empty list.

And I use an explicit initialization to `nil' or `()' in a `let',
if it is a true initialization.  That is, I put a variable in a
`let' without any initial value _only_ if its initial value is
assigned in the `let' body, i.e., without making any use of its
implicit initial nil value.  

And I put any variables that have no initial binding at the end
of the list of bindings (not at the beginning, and not in between).

And yes, these conventions mean that I have to rewrite code from
one form to another as it evolves.  Not a big deal, to me.
Reading code is more important, to me.

I make no claims about others sharing such conventions.

Re: if vs. when vs. and: style question

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> In general, WHEN is better than IF.
>
> Also, (unless (e1) (e2)) is better than (if (not (e1))
> (e2)).
>
> Notably, WHEN and UNLESS have an implicit progn:

"In general", you say. Is there any other advantage
save for not having to do the explicit `progn' and/or
`not'?

For almost no one is LISP the first language learned.
By the time most people stumble upon LISP they have
already written on zillions of if clauses. So I think
`if' is clearer and the explicit `progn' and `not'
doesn't bother me, but both (all) ways are good.

> So you can typically have functions such as:
>
>   (defun find-thingy (name) (or
> (find-thingy-in-whatcha name) (find-thingy-in-macall
> name) (find-thingy-in-it name) (error "not found")))
>
> which is much more concise and clear than ...

But is it clearer than

    (defun look-here () "here")

    (cond
     ((look-here))
     ((look-there))
     (t (message "Not found")))

as well? I always thought of `cond' and `if' as
identical save for syntax.

-- 
underground experts united

Re: if vs. when vs. and: style question

[Rusi]

On Tuesday, March 24, 2015 at 7:54:43 AM UTC+5:30, Emanuel Berg wrote:
> "Pascal J. Bourguignon"  writes:
> 
> > In general, WHEN is better than IF.
> >
> > Also, (unless (e1) (e2)) is better than (if (not (e1))
> > (e2)).
> >
> > Notably, WHEN and UNLESS have an implicit progn:
> 
> "In general", you say. Is there any other advantage
> save for not having to do the explicit `progn' and/or
> `not'?

In general weaker is better
http://www.w3.org/2001/tag/doc/leastPower.html

(when a b) ≡ (if a b)
However (if a b c) ≡ (when ??)

Other example:

destructuring-bind is strictly weaker than if/cond and so better when usable

Re: if vs. when vs. and: style question

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> In general weaker is better
> http://www.w3.org/2001/tag/doc/leastPower.html
>
> (when a b) ... (if a b) However (if a b c) ... (when ??)

What do you mean by "weaker"?

`if' can do three arguments, on the other hand it
needs a `progn' to do several forms. `when' comes with
implicit progn but cannot do the three way
if-else if-else branch.

What I can see `if' is more flexible and you can
change things without having to change the outermost
`if', which is practical. Yes, with the use of `not'
and `progn' if necessary, but I don't see a problem
with that.

> Other example:
>
> destructuring-bind is strictly weaker than if/cond
> and so better when usable

What is "destructuring-bind"?

What do you mean by "strictly weaker"? ("Strictly
less" is (a < b) as opposed to (a <= b) which is
"less than or equal".)

If what you mean by "weaker" is some attempt at
a formalization of "you can do less" then I do not
agree that should be preferred by definition.

For example, here

    (1+ 5)  ; 6
    (+ 1 5) ; 6

I'm sure (1+ 5) looks better to some, but think it is
even steven. It depends. The (+ ... ) construct is
very familiar. And there, the "1" can be changed, or
replaced by a variable name.

If you use the most powerful construct, you can stick
to that, everywhere. The code looks uniform and is
fast to edit.

Of course, if you do enough `when' and `unless' and
three-way `if's then it will probably all look uniform
to you pretty soon, as well. Personally I prefer only
`if's but I'm only mildly passionate about it.
For example, if I inherited code I wouldn't change the
`when's and `unless'es.

-- 
underground experts united

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> If what you mean by "weaker" is some attempt at
> a formalization of "you can do less" then I do not
> agree that should be preferred by definition.
>
> For example, here
>
>     (1+ 5)  ; 6
>     (+ 1 5) ; 6

But then, why stop with +?

You could use instead:

   (funcall (additive-operator (ring integer))
            (neutral-element (multiplicative-operator (ring integer)))
            5) ; 6

or something even more general?


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> But then, why stop with +?
>
> You could use instead:
>
>    (funcall (additive-operator (ring integer))
> (neutral-element (multiplicative-operator (ring
> integer))) 5) ; 6
>
> or something even more general?

OK, the rule should be respelled "the most general
method wich is still instantly recognizable as serving
its specific purpose".

In this example, the data could be hard coded (with
+), so it can be replaced easily when patterns appear
(i.e., the sama data appears several times). So the
data is hard coded now so not to be later (or, if it
simply needs to be changed, as said).

With `1+', in that case the operator would have to be
replaced. But I don't want to do that and especially
not if I can remedy the problem by just changing data.

-- 
underground experts united

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 8:10:18 AM UTC+5:30, Emanuel Berg wrote:
> "Pascal J. Bourguignon"  writes:
> 
> > But then, why stop with +?
> >
> > You could use instead:
> >
> >    (funcall (additive-operator (ring integer))
> > (neutral-element (multiplicative-operator (ring
> > integer))) 5) ; 6
> >
> > or something even more general?

I find Pascal's example brilliant and hilarious.
In this case though, I slightly err on your (Emanuel) side.

When I see the 1+, I have a stop (like um... er...)
Is that a number, an expression, a constant, a comment?

Oh Oh.. Functions can start with digits (Yeah this is lisp...)

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Rusi <rustompmody@gmail.com> writes:

> On Wednesday, March 25, 2015 at 8:10:18 AM UTC+5:30, Emanuel Berg wrote:
>> "Pascal J. Bourguignon"  writes:
>> 
>> > But then, why stop with +?
>> >
>> > You could use instead:
>> >
>> >    (funcall (additive-operator (ring integer))
>> > (neutral-element (multiplicative-operator (ring
>> > integer))) 5) ; 6
>> >
>> > or something even more general?
>
> I find Pascal's example brilliant and hilarious.
> In this case though, I slightly err on your (Emanuel) side.
>
> When I see the 1+, I have a stop (like um... er...)
> Is that a number, an expression, a constant, a comment?
>
> Oh Oh.. Functions can start with digits (Yeah this is lisp...)


Indeed, it is clear that the names 1+ and 1- are ill-choosen.
Notably 1-!!!

            (1- x) == (- x 1)


BUT

Those are actually fundamental operators, more fundamental than addition
and substration, both in a theoric way, and in practice with a lot of
processors.

They are the operators named succ(x) and pred(x) in pascal (which C
lacks as independent operators, but have combined with updating with the
pre- and post- complifications of ++x, x++, --x, and x--; C is THE crazy
language).


In axiomatic number/set theory, we only assume a number noted 0, and a
succ(x) operation that let us build a new number from any number x.

so 1 = succ(0) by definition.  (= 1 (1+ 0))

You do not program it the other way around, defining 1+ from x and 1,
you define 1 from 1+ and 0!

And the proof, is that processors usually have an increment and a
decrement operation even while they may lack a general load operation
(working or any immediate word-sized number).

So when you write x:=512; you may actually obtain a "load #511; incr"
instruction sequence, ie. (1+ 511).



So write: 

   (defun succ (x) (1+ x)) 
   (defun pred (x) (1- x)) 

or in elisp:

   (defalias 'succ '1+)
   (defalias 'pred '1-)

and use (succ x) instead of (1+ x) or (+ x 1).


(Remember that the only literal numbers allowed in a program source are
0 and 1; well, it's even better if you allow only 0 and (succ x)).

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 12:49:59 PM UTC+5:30, Pascal J. Bourguignon wrote:
> Rusi writes:
> 
> > On Wednesday, March 25, 2015 at 8:10:18 AM UTC+5:30, Emanuel Berg wrote:
> >> "Pascal J. Bourguignon"  writes:
> >> 
> >> > But then, why stop with +?
> >> >
> >> > You could use instead:
> >> >
> >> >    (funcall (additive-operator (ring integer))
> >> > (neutral-element (multiplicative-operator (ring
> >> > integer))) 5) ; 6
> >> >
> >> > or something even more general?
> >
> > I find Pascal's example brilliant and hilarious.
> > In this case though, I slightly err on your (Emanuel) side.
> >
> > When I see the 1+, I have a stop (like um... er...)
> > Is that a number, an expression, a constant, a comment?
> >
> > Oh Oh.. Functions can start with digits (Yeah this is lisp...)
> 
> 
> Indeed, it is clear that the names 1+ and 1- are ill-choosen.
> Notably 1-!!!
> 
>             (1- x) == (- x 1)
> 
> 
> BUT
> 
> Those are actually fundamental operators, more fundamental than addition
> and substration, both in a theoric way, and in practice with a lot of
> processors.
> 
> They are the operators named succ(x) and pred(x) in pascal (which C
> lacks as independent operators, but have combined with updating with the
> pre- and post- complifications of ++x, x++, --x, and x--; C is THE crazy
> language).
> 
> 
> In axiomatic number/set theory, we only assume a number noted 0, and a
> succ(x) operation that let us build a new number from any number x.
> 
> so 1 = succ(0) by definition.  (= 1 (1+ 0))
> 
> You do not program it the other way around, defining 1+ from x and 1,
> you define 1 from 1+ and 0!
> 
> And the proof, is that processors usually have an increment and a
> decrement operation even while they may lack a general load operation
> (working or any immediate word-sized number).
> 
> So when you write x:=512; you may actually obtain a "load #511; incr"
> instruction sequence, ie. (1+ 511).
> 
> 
> 
> So write: 
> 
>    (defun succ (x) (1+ x)) 
>    (defun pred (x) (1- x)) 
> 
> or in elisp:
> 
>    (defalias 'succ '1+)
>    (defalias 'pred '1-)
> 
> and use (succ x) instead of (1+ x) or (+ x 1).
> 
> 
> (Remember that the only literal numbers allowed in a program source are
> 0 and 1; well, it's even better if you allow only 0 and (succ x)).


You are in a funny mood today Pascal!!

Yeah I know that math pre-exists the universe...
And arithmetic is core math
And Peano's axioms are the heart of arithmetic
Yeah Yeah I know I know...

Still choosing identifiers in a programming language (even Lisp!)
to align with Peano's axioms seems a bit much... Dont you think?

On a different note...
For 50 years CS has been living in the impoverished world of ASCII.
This makes people think CS and math are more far apart than they essentially/really are.

I wrote this as my wish for python:
http://blog.languager.org/2014/04/unicoded-python.html
Isn't it about time lisp also considered a similar line?

Re: if vs. when vs. and: style question

[Stefan Monnier]

> For 50 years CS has been living in the impoverished world of ASCII.
> This makes people think CS and math are more far apart than they
> essentially/really are.

You might like to take a look at the Agda language,


        Stefan

Re: if vs. when vs. and: style question now Unicode

[Dan Espen]

Rusi <rustompmody@gmail.com> writes:

> On a different note...
> For 50 years CS has been living in the impoverished world of ASCII.
> This makes people think CS and math are more far apart than they essentially/really are.
>
> I wrote this as my wish for python:
> http://blog.languager.org/2014/04/unicoded-python.html
> Isn't it about time lisp also considered a similar line?

I can't type it, I sure don't want to see it in source code.

-- 
Dan Espen

Re: if vs. when vs. and: style question now Unicode

[Rusi]

On Wednesday, March 25, 2015 at 8:22:28 PM UTC+5:30, Dan Espen wrote:
> Rusi  writes:
> 
> > On a different note...
> > For 50 years CS has been living in the impoverished world of ASCII.
> > This makes people think CS and math are more far apart than they essentially/really are.
> >
> > I wrote this as my wish for python:
> > http://blog.languager.org/2014/04/unicoded-python.html
> > Isn't it about time lisp also considered a similar line?
> 
> I can't type it, I sure don't want to see it in source code.

Strange to see that comment on an emacs-list!

I guess the same comment would have been made 50 years ago when C came out
and Fortran/Cobol programmers could not find lower case on card-punch machines

[There are things called input-methods in particular tex-input method]¹


Yes, unicode has more mis-understandings than understanding (currently)
See

http://blog.languager.org/2015/02/universal-unicode.html for the plus
http://blog.languager.org/2015/03/whimsical-unicode.html for the minus


=========
¹ I prefer X-based input methods; eg after
$ setxkbmap -layout "us,gr"  -option "grp:caps_toggle,grp_led:caps"

the CAPSLOCK becomes a 'greeklock' ie after pressing CAPSLOCK
abcdefghijklmnopqrstuvwxyz
produces
αβψδεφγηιξκλμνοπ;ρστθωςχυζ

Re: if vs. when vs. and: style question now Unicode

[Dan Espen]

Rusi <rustompmody@gmail.com> writes:

> On Wednesday, March 25, 2015 at 8:22:28 PM UTC+5:30, Dan Espen wrote:
>> Rusi  writes:
>> 
>> > On a different note...
>> > For 50 years CS has been living in the impoverished world of ASCII.
>> > This makes people think CS and math are more far apart than they essentially/really are.
>> >
>> > I wrote this as my wish for python:
>> > http://blog.languager.org/2014/04/unicoded-python.html
>> > Isn't it about time lisp also considered a similar line?
>> 
>> I can't type it, I sure don't want to see it in source code.
>
> Strange to see that comment on an emacs-list!

I've been using Emacs since the 70s.

> I guess the same comment would have been made 50 years ago when C came out
> and Fortran/Cobol programmers could not find lower case on card-punch machines
>
> [There are things called input-methods in particular tex-input method]¹
>
>
> Yes, unicode has more mis-understandings than understanding (currently)
> See
>
> http://blog.languager.org/2015/02/universal-unicode.html for the plus
> http://blog.languager.org/2015/03/whimsical-unicode.html for the minus
>
>
> =========
> ¹ I prefer X-based input methods; eg after
> $ setxkbmap -layout "us,gr"  -option "grp:caps_toggle,grp_led:caps"
>
> the CAPSLOCK becomes a 'greeklock' ie after pressing CAPSLOCK
> abcdefghijklmnopqrstuvwxyz
> produces
> αβψδεφγηιξκλμνοπ;ρστθωςχυζ

That's pretty neat.
But I don't know the Greek alphabet and if someone started sprinkling
Greek in my source code, I'd want a damn good explanation.

There are thousands of these crazy symbols and around 100 keys on my
keyboard.  Only a few of those keys have more than 1 label.

How am I supposed to remember how to type all this stuff?

-- 
Dan Espen

Re: if vs. when vs. and: style question now Unicode

[Rusi]

On Wednesday, March 25, 2015 at 9:16:21 PM UTC+5:30, Dan Espen wrote:
> Rusi  writes:
> 
> > On Wednesday, March 25, 2015 at 8:22:28 PM UTC+5:30, Dan Espen wrote:
> >> Rusi  writes:
> >> 
> >> > On a different note...
> >> > For 50 years CS has been living in the impoverished world of ASCII.
> >> > This makes people think CS and math are more far apart than they essentially/really are.
> >> >
> >> > I wrote this as my wish for python:
> >> > http://blog.languager.org/2014/04/unicoded-python.html
> >> > Isn't it about time lisp also considered a similar line?
> >> 
> >> I can't type it, I sure don't want to see it in source code.
> >
> > Strange to see that comment on an emacs-list!
> 
> I've been using Emacs since the 70s.
> 
> > I guess the same comment would have been made 50 years ago when C came out
> > and Fortran/Cobol programmers could not find lower case on card-punch machines
> >
> > [There are things called input-methods in particular tex-input method]¹
> >
> >
> > Yes, unicode has more mis-understandings than understanding (currently)
> > See
> >
> > http://blog.languager.org/2015/02/universal-unicode.html for the plus
> > http://blog.languager.org/2015/03/whimsical-unicode.html for the minus
> >
> >
> > =========
> > ¹ I prefer X-based input methods; eg after
> > $ setxkbmap -layout "us,gr"  -option "grp:caps_toggle,grp_led:caps"
> >
> > the CAPSLOCK becomes a 'greeklock' ie after pressing CAPSLOCK
> > abcdefghijklmnopqrstuvwxyz
> > produces
> > αβψδεφγηιξκλμνοπ;ρστθωςχυζ
> 
> That's pretty neat.
> But I don't know the Greek alphabet and if someone started sprinkling
> Greek in my source code, I'd want a damn good explanation.

Greek was given as an example

> 
> There are thousands of these crazy symbols and around 100 keys on my
> keyboard.  Only a few of those keys have more than 1 label.

1 million+ codepoints
Greater 100,000 in use

> 
> How am I supposed to remember how to type all this stuff?

You are asking a rhetorical question...

If you are asking genuinely:
http://blog.languager.org/2015/01/unicode-and-universe.html
explains what's wrong with sticking to the obsolete penury-of-ASCII

http://blog.languager.org/2015/02/universal-unicode.html
suggests that if mapping a million chars onto a 100-char keyboard looks like
an unpleasant/unsolvable problem, which subsets may be worth considering

Re: if vs. when vs. and: style question now Unicode

[Dan Espen]

Rusi <rustompmody@gmail.com> writes:

> On Wednesday, March 25, 2015 at 9:16:21 PM UTC+5:30, Dan Espen wrote:
>> Rusi  writes:
>> 
>> > On Wednesday, March 25, 2015 at 8:22:28 PM UTC+5:30, Dan Espen wrote:
>> >> Rusi  writes:
>> >> 
>> >> > On a different note...
>> >> > For 50 years CS has been living in the impoverished world of ASCII.
>> >> > This makes people think CS and math are more far apart than they essentially/really are.
>> >> >
>> >> > I wrote this as my wish for python:
>> >> > http://blog.languager.org/2014/04/unicoded-python.html
>> >> > Isn't it about time lisp also considered a similar line?
>> >> 
>> >> I can't type it, I sure don't want to see it in source code.
>> >
>> > Strange to see that comment on an emacs-list!
>> 
>> I've been using Emacs since the 70s.
>> 
>> > I guess the same comment would have been made 50 years ago when C came out
>> > and Fortran/Cobol programmers could not find lower case on card-punch machines
>> >
>> > [There are things called input-methods in particular tex-input method]¹
>> >
>> >
>> > Yes, unicode has more mis-understandings than understanding (currently)
>> > See
>> >
>> > http://blog.languager.org/2015/02/universal-unicode.html for the plus
>> > http://blog.languager.org/2015/03/whimsical-unicode.html for the minus
>> >
>> >
>> > =========
>> > ¹ I prefer X-based input methods; eg after
>> > $ setxkbmap -layout "us,gr"  -option "grp:caps_toggle,grp_led:caps"
>> >
>> > the CAPSLOCK becomes a 'greeklock' ie after pressing CAPSLOCK
>> > abcdefghijklmnopqrstuvwxyz
>> > produces
>> > αβψδεφγηιξκλμνοπ;ρστθωςχυζ
>> 
>> That's pretty neat.
>> But I don't know the Greek alphabet and if someone started sprinkling
>> Greek in my source code, I'd want a damn good explanation.
>
> Greek was given as an example
>
>> 
>> There are thousands of these crazy symbols and around 100 keys on my
>> keyboard.  Only a few of those keys have more than 1 label.
>
> 1 million+ codepoints
> Greater 100,000 in use

So, 100 keys and about a dozen distinct shift keys used one or 2 at a
time should just about cover it.

Putting anything useful on the key caps is not in the cards.

>> How am I supposed to remember how to type all this stuff?
>
> You are asking a rhetorical question...
>
> If you are asking genuinely:
> http://blog.languager.org/2015/01/unicode-and-universe.html
> explains what's wrong with sticking to the obsolete penury-of-ASCII
>
> http://blog.languager.org/2015/02/universal-unicode.html
> suggests that if mapping a million chars onto a 100-char keyboard looks like
> an unpleasant/unsolvable problem, which subsets may be worth considering

Obvious to me, allowing 100,000 characters into source code
is a really bad idea.

How many additional characters do you think a language should allow?

I ended up expending quite a bit of effort to get square brackets to
work right on an IBM mainframe.
The PL/I not sign and solid bar vs. broken bar still
cause problems.  Then I still run into this: ¢.

I have no idea how I'd deal with any significant number of new
characters.

-- 
Dan Espen

Re: if vs. when vs. and: style question now Unicode

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Greek was given as an example

Greek, Russian, etc. is good for
"non-computer computer use", for example when you
write a mail to your mother asking her to send more
money because you lost them on a horse race, after
which you had to pay the doctor to put your body
back together.

No one, not even the Greeks or Russians themselves,
thinks it is a good idea to *program* using those
chars and languages. Just as only novice Spaniards
thinks it is a good idea to program in Spanish!

>> How am I supposed to remember how to type all
>> this stuff?
>
> You are asking a rhetorical question...

Let me ask you a serious question: What advantage can
be reached if one not only could remember all this
stuff, but actually used it as well? Why would anyone
benefit from that, and how? What problems could be
solved, and what insights derived, which cannot be
done so today, right now, with no fuss, with ASCII?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question now Unicode

[Rusi]

On Wednesday, March 25, 2015 at 9:16:21 PM UTC+5:30, Dan Espen wrote:
> There are thousands of these crazy symbols and around 100 keys on my
> keyboard.  Only a few of those keys have more than 1 label.

Ive not seen your keyboard. Yet am ready to bet that for your keyboard:
- There is a key whose 'label' looks like 'A'
- There is no key whose label looks like 'a'
- Yet when you type that key you get an 'a' not an 'A'
- That there is no way using your keyboard to get a 'a' with a single-keystroke

[Also I bet you've heard of an editor named after the chord-chars
Escape-Meta-Alt-Control-Shift
]

In short...
> 
> How am I supposed to remember how to type all this stuff?

You are already using an 'input-method' any-which-how already.
Inside emacs you are using probably hundreds of chords and chord-sequences that
are completely un-memonic – What the hell does C-x C-c have to do with terminating?
And what about the 4-char-chord M-C-S-% for query-replace-regexp ?

We can use more sophisticated ones for richer charsets (if we wish)

tl;dr
US-104 ≠ ASCII

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Rusi <rustompmody@gmail.com> writes:

> For 50 years CS has been living in the impoverished world of ASCII.
> This makes people think CS and math are more far apart than they essentially/really are.
>
> I wrote this as my wish for python:
> http://blog.languager.org/2014/04/unicoded-python.html
> Isn't it about time lisp also considered a similar line?

Take a random computer.  Type λ.  Type lambda.  Which one was easier?

Type:   ∀ ρ∈W • 𝐑ρ □
Type:   (for-all (member rho W) (R rho))

Which one was easier?

However, check:
https://gitlab.com/com-informatimago/emacs/blob/master/pjb-sources.el#L703

With this font-lock, you type (lambda (epsilon) (* 2 epsilon))
and you see: (λ (ε) (* 2 ε))
the buffer and file still contain (lambda (epsilon) (* 2 epsilon))
but it's displayed as greek letters.
This can of course be expanded to more unicode symbols.


You could type: (for-all (member rho W) (mathematical-bold-capital-r rho))
and you'd see:  (∀ (∈ ρ W) (𝐑 ρ))


The next step, is to use a system like HAL/S or the one implemented for
scheme -> LaTeX, which reformat formulae in sources using a Mathematic
rendering engine such as LaTeX (or ASCII art in the case of HAL/S).

The important point is that you keep the source in ASCII, so it's easy
to type and to process anywhere.

The difficulty is that you have to maintain a (possibly complex)
toolchain to have nice renderings.


The success of lisp and unix over the decades shows that simplier tools
win on the long term.   Contrarily to graphic programming languages (such
as UML) or other "experiments", or more complex systems, object-based or
other (LispMachines), which will eventually break and be forgotten by
most and regretted by few).


(Everytime I touch UML, there's a whole new toolchain or CASE tool as
the tool du jour.  Everytime I touch lisp sources, I have my faithful
emacs, and what we do today with emacs 24, you could do thirty years ago
with emacs 18).


Perhaps unicode will take over programming sources, when we'll be able
to input your programs by mind reading devices instead of keyboards.
But it won't be soon, if you check how bad it is only to dictate
program sources (vs. English text).

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 9:00:46 PM UTC+5:30, Pascal J. Bourguignon wrote:
> Rusi  writes:
> 
> > For 50 years CS has been living in the impoverished world of ASCII.
> > This makes people think CS and math are more far apart than they essentially/really are.
> >
> > I wrote this as my wish for python:
> > http://blog.languager.org/2014/04/unicoded-python.html
> > Isn't it about time lisp also considered a similar line?
> 
> Take a random computer.  Type λ.  Type lambda.  Which one was easier?

Take a random computer. Start notepad
Take a random computer. Start emacs
Work out the relative probabilities of failure

Sorry... "Random computer" arguments dont work (or can be made to work any way
you choose)

Re: if vs. when vs. and: style question

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Take a random computer. Start notepad Take a random
> computer. Start emacs Work out the relative
> probabilities of failure
>
> Sorry... "Random computer" arguments dont work (or
> can be made to work any way you choose)

It does work and that is the reason to have a small
common ground and then put complexity like LaTeX or
whatever at the endpoints so that
techno-techno-neurotics can have their way with it
while actual work is carried out elsewhere with the
tools that are suitable for that purpose.

Think for example of fire fighters. They have a lot of
equipment and protection in their trucks, and some
attached to their bodies.

But as there are so many unique situations and
combinations thereof that can produce a plethora of
immediate problems they must nonetheless tackle in
a short time frame, why don't they have ten times the
amount of equipment? Or one hundred times as much?
The exact right thing for any situation? And not just
things - human resources, as well? Why not?

1) It is *impractical* to the point of being
   totally unrealistic.

2) With training with the basic tools and methods,
   even though the specialized one objectively are
   "better", in reality, the outcome (effect) is still
   much better with the basic toolset.

If the average life of a man was 1500 years and with
mental capabilities to match it perhaps we could
achieve the super-specialization and scientificness
you dream of. Instead, it is about mastering a craft
including the good habits and all conventional wisdom
to it - and there is never enough time, either.

It is the domain which I call: reality.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 9:00:46 PM UTC+5:30, Pascal J. Bourguignon wrote:
> Rusi  writes:
> 
> > For 50 years CS has been living in the impoverished world of ASCII.
> > This makes people think CS and math are more far apart than they essentially/really are.
> >
> > I wrote this as my wish for python:
> > http://blog.languager.org/2014/04/unicoded-python.html
> > Isn't it about time lisp also considered a similar line?
> 
> Take a random computer.  Type λ.  Type lambda.  Which one was easier?
> 
> Type:   ∀ ρ∈W • 𝐑ρ □
> Type:   (for-all (member rho W) (R rho))
> 
> Which one was easier?
> 
> However, check:
> https://gitlab.com/com-informatimago/emacs/blob/master/pjb-sources.el#L703
> 
> With this font-lock, you type (lambda (epsilon) (* 2 epsilon))
> and you see: (λ (ε) (* 2 ε))
> the buffer and file still contain (lambda (epsilon) (* 2 epsilon))
> but it's displayed as greek letters.
> This can of course be expanded to more unicode symbols.
> 
> 
> You could type: (for-all (member rho W) (mathematical-bold-capital-r rho))
> and you'd see:  (∀ (∈ ρ W) (𝐑 ρ))
> 
> 
> The next step, is to use a system like HAL/S or the one implemented for
> scheme -> LaTeX, which reformat formulae in sources using a Mathematic
> rendering engine such as LaTeX (or ASCII art in the case of HAL/S).
> 
> The important point is that you keep the source in ASCII, so it's easy
> to type and to process anywhere.


Ive elaborated some of these points here
http://blog.languager.org/2015/01/unicode-and-universe.html

Re: if vs. when vs. and: style question

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

>> For 50 years CS has been living in the impoverished
>> world of ASCII. This makes people think CS and math
>> are more far apart than they essentially/really
>> are. I wrote this as my wish for python:
>> http://blog.languager.org/2014/04/unicoded-python.html
>> Isn't it about time lisp also considered
>> a similar line?
>
> Take a random computer. Type λ. Type lambda.
> Which one was easier?

It is much easier, quicker, and more pleasant to type
"lambda" even though that word isn't the easiest to
type.

It is also much easier and more pleasant to read, and
we (even the Greek when it comes to computing) have
a landslide more experience doing it.

> With this font-lock, you type (lambda (epsilon) (* 2
> epsilon)) and you see: (λ (ε) (* 2 ε)) the buffer
> and file still contain (lambda (epsilon) (* 2
> epsilon)) but it's displayed as greek letters.
> This can of course be expanded to more
> unicode symbols.

It can, but it is better if you see what you type when
you type it, and later, you see exactly what you once
typed and what still is in effect and nothing else.

To have the equivalence of several hundred abbrevs all
expanding back and forth is plain seasickness, which
by the way has been the cause of countless of suicides
during centuries of naval bravado.

> The next step, is to use a system like HAL/S or the
> one implemented for scheme -> LaTeX, which reformat
> formulae in sources using a Mathematic rendering
> engine such as LaTeX (or ASCII art in the case of
> HAL/S).

LaTeX should be used for very specific cases when you
do super-ambitious documents, like manuals and
university papers, that are to be read by *humans*
(who use different computers and printers), documents
that are likely not change continuously other than the
occasional fix, and documents that contain tons of
strange notation because they are intended for the
scientific community of whatever branch they belong.

LaTeX should not be used for the web just as HTML
should not be used in mails. I know it is possible -
question is: is it *sensible*?

To have LaTeX style *programming* is first grade
lunacy: I'd say just a few circuits from short
circuiting. It would be impractical and time-consuming
beyond belief. Just compare the time it takes to write
this mail - no time - to the time typesetting it in
LaTeX. With the \documentclass and packaged and
\subsections and all. You can spend hours on that.

ASCII should always be used for anything that is
intended to be computer used, computed, portab...
no: interchangeable!

> The important point is that you keep the source in
> ASCII, so it's easy to type and to process anywhere.

That's exactly right - and that's the whole thing and
purpose and appeal of it. So if you didn't notice it
by intuition and common sense it is logical as well.

So, apart from the easy, pleasant and consistent input
and much more convenient reading, ASCII also wins the
computer-computer interaction battle, and not just the
human-computer ditto.

> The success of lisp and unix over the decades shows
> that simplier tools win on the long term.
> Contrarily to graphic programming languages (such as
> UML) or other "experiments", or more complex
> systems, object-based or other (LispMachines), which
> will eventually break and be forgotten by most and
> regretted by few).

One hundred percent correct! All those silly tools are
intended so the programmer can be replaced by people
who cannot program. So far that hasn't happen - and
I am confident it never will.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Rusi]

On Sunday, March 29, 2015 at 6:29:45 AM UTC+5:30, Emanuel Berg wrote:
> "Pascal J. Bourguignon" 
> > The success of lisp and unix over the decades shows
> > that simplier tools win on the long term.
> > Contrarily to graphic programming languages (such as
> > UML) or other "experiments", or more complex
> > systems, object-based or other (LispMachines), which
> > will eventually break and be forgotten by most and
> > regretted by few).
> 
> One hundred percent correct! All those silly tools are
> intended so the programmer can be replaced by people
> who cannot program. So far that hasn't happen - and
> I am confident it never will.

Its important to distinguish and orthogonalize two aspects:
1. Linearity
2. Charset

Starting from Turing's paper where he 'created' his machine, the big jump
from normal math to Turing-math (which would later become CS) was linearity.
Turing asks us to imagine a mathematician doing a computation on paper
(shortform compute-er!) and then goes on to show that the paper can be 
linearized  into a 'tape'.

This linearity persists today in our computers whose memories are linear
sequences of bytes numbered 0 to 4G (or whatever).
Likewise files are sequences of bytes.

Then, because we humans dont like linearity too much, we have devices like
- emacs that non-linearizes a file on disk into a 2-D display
- file-systems that non-linearize a block into a file-system
- and so on.

So html for example non-linearizes a linear text.
Unicode (charset in general) doesn't (ok there's bidi codes but ignoring that).

Things like UML are difficult and problematic because of non-linearity not charset.

There are at least half-a-dozen programming languages and systems I can think of
that are already unicode-capable:

From venerable to cutting-edge:
APL, Appletalk, Fortress,  Erlang, Python, Julia, Haskell, Agda,

And even Elisp!

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (setq α 1 β 2 γ 3)
3 (#o3, #x3, ?\C-c)
ELISP> (list α β γ)
(1 2 3)

ELISP> 

How much costly was that α to type than alpha?? One backslash!!

Add to that the fact that programs are read
- 10 times more than written during development
- 100 times more during maintenance

Re: if vs. when vs. and: style question

[Rusi]

On Sunday, March 29, 2015 at 8:12:01 AM UTC+5:30, Rusi wrote:
> And even Elisp!
> 
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> (setq α 1 β 2 γ 3)
> 3 (#o3, #x3, ?\C-c)
> ELISP> (list α β γ)
> (1 2 3)
> 
> ELISP> 

And if you think Greek is only for the Greeks:

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (setq x₁ 1 x₂ 2 x₃ 3)
3 (#o3, #x3, ?\C-c)
ELISP> (list x₁ x₂ x₃)
(1 2 3)

ELISP>

Re: if vs. when vs. and: style question

[Óscar Fuentes]

Rusi <rustompmody@gmail.com> writes:

[snip]

> And even Elisp!
>
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> (setq α 1 β 2 γ 3)
> 3 (#o3, #x3, ?\C-c)
> ELISP> (list α β γ)
> (1 2 3)

Some months ago I experimented with using Unicode on my coding. I was
very excited about it. At the end, the experience showed without a doubt
that it is a bad idea. One of the reasons is very familiar to us: a
funtamental feature of a programmer's font is how clearly it
distinguishes 1 from l, 0 from O. Using Unicode makes this problem
explode.

> ELISP> 
>
> How much costly was that α to type than alpha?? One backslash!!
>
> Add to that the fact that programs are read
> - 10 times more than written during development
> - 100 times more during maintenance

Precisely, my experience is that Unicode makes things much harder to
read, and not ony because the problem mentioned above.

RE: if vs. when vs. and: style question

[Drew Adams]

> Some months ago I experimented with using Unicode on my coding. I was
> very excited about it. At the end, the experience showed without a doubt
> that it is a bad idea. One of the reasons is very familiar to us: a
> funtamental feature of a programmer's font is how clearly it
> distinguishes 1 from l, 0 from O. Using Unicode makes this problem
> explode.

+1.  That is a problem, in general.

There are no doubt ways to mitigate it (font choice? highlighting?
font size?), and that might make it worthwhile for some people in
some contexts.  But visual clarity is definitely important.

Even just knowing that more than the usual set of chars (e.g. ASCII)
might be involved forces readers to look more carefully.  If they
know that only ASCII is involved then they are probably already
(e.g. unconsciously) paying attention to possible confusions such
as `1' and `l'.

For the same reason, adding more chars as possibilities also means
that users can need to even more carefully choose a font, finding
one that distinguishes such things well.  Fonts that people have
commonly been using for programming typically distinguish the
possible ASCII confusions pretty well.

> > How much costly was that α to type than alpha?? One backslash!!
> >
> > Add to that the fact that programs are read
> > - 10 times more than written during development
> > - 100 times more during maintenance
> 
> Precisely, my experience is that Unicode makes things much harder to
> read, and not ony because the problem mentioned above.

What other problems would you point out in this regard?

Re: if vs. when vs. and: style question

[Óscar Fuentes]

Drew Adams <drew.adams@oracle.com> writes:

[snip]

>> Precisely, my experience is that Unicode makes things much harder to
>> read, and not ony because the problem mentioned above.
>
> What other problems would you point out in this regard?

Derivations of the case you mentioned on your reply to me. Essentially
you are bound to a font if you want to ensure readability. When you
publish a book or a paper it is natural to select the most convenient
font. However, it is not so natural to state "the source code contained
on this file is best read with DejaVu Sans Mono, Caveat Emptor".

In general, applying the rules of publishing to source code produces
nice results on the terminal of the code writer, but surprises
elsewhere.

Another issue is related to what Pascal Bourguignon mentions, and my
reply to Stefan: the abundance of symbols adds mental strain.
Furthermore, using shorter textual representations for objects makes the
code almost cryptic, moreso when such representations uses symbols taken
from a large pool. That's my experience and, IIRC, there are studies
that back that impression. The usual advice about descriptive names and
self-documenting code applies.

Then we have the community problem: you are adding a whole new set of
requirements to everyone who needs to work with your code. They must use
certain fonts, with certain editors, then learn the conventions about
the used/acceptable symbols... This opens a whole new world of
opportunities for bikeshedding :-)

OTOH, inputting the symbols, which seems to be a hot topic on this
thread, was no problem, by my tolerance thresholds.

Re: if vs. when vs. and: style question

[Rusi]

On Monday, March 30, 2015 at 7:25:42 AM UTC+5:30, Óscar Fuentes wrote:
> Another issue is related to what Pascal Bourguignon mentions, and my
> reply to Stefan: the abundance of symbols adds mental strain.
> Furthermore, using shorter textual representations for objects makes the
> code almost cryptic, moreso when such representations uses symbols taken
> from a large pool. That's my experience and, IIRC, there are studies
> that back that impression.

One of the most fundamental DNAs of a programmer is what we may call
'batch-moding'  Examples from more specialized to more universal:

- preprocessing string search to get fancy algorithms like KMP
- Use a compiler rather than an interpreter
- Write a program (to do a computation) rather than do the computation
 (on pen-paper)

The same principle applies to the wetware in the box atop our shoulders.
So if you take Stefan's



has_type env exp type

vs
   
Γ ⊢ e : τ 

The first is ok and preferable to the second if its to be written once 
(or a few times).  As it becomes increasingly frequent the demand for
(something like) the second will correspondingly increase.

"Something like" because

Stefan: 
> Some of those letters/signs have meaning shared within a fairly large mathematical
> community while others are much more specific to a specialized subfield.

Here are TWO points that are separate and deserve orthogonalization
1. Mathematicians do good compression of their subject
2. Mathematics is a cottage industry – one uses gzip, one LZ, one good-old huffman

Many arguments seemingly against the first, are under the hood, arguments 
against the second.

> The usual advice about descriptive names and
> self-documenting code applies.

Yes... Between


has_type env exp type

vs
   
Γ ⊢ e : τ 

Some will find the second frightening; the first ok
Some will find it exactly the opposite -- "prose" and "prolix" are quite close

How much are these judgments objective? Genetic-structural? Just plain
illiteracy/bad-habits??  Open questions...
[And questions unrelated IMHO to the systems used by a certain Mr. Noah to 
design a large boat on which our ancestors were collected]
-------------------
tl;dr Unicode is an ISO standard – something mathematicians have never heard of.
Seems like a good idea to take their knowledge and discard their ignorance

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Rusi <rustompmody@gmail.com> writes:

> And even Elisp!
>
> *** Welcome to IELM ***  Type (describe-mode) for help.
> ELISP> (setq α 1 β 2 γ 3)
> 3 (#o3, #x3, ?\C-c)
> ELISP> (list α β γ)
> (1 2 3)
>
> ELISP> 
>
> How much costly was that α to type than alpha?? One backslash!!
>
> Add to that the fact that programs are read
> - 10 times more than written during development
> - 100 times more during maintenance

This is a good point.  And the answer to it, is that mathematicians
habit of using extra alphabets, comes not from reading, but from
writing.  It's a kind of steno for mathematicians.  Also, it denotes a
lack of abstraction on their part.  Abstraction is the naming of
concepts.  They have to use a stenographical notation because they don't
give names to their concepts, so they have to write and rewrite again
and again the same formulae, hence the need for short notations.

This is not made for reading.  (And the work of Sussman clearly shows
it).

What is α?  What is β?

Wouldn't have it been better to name those variables number-of-rows
or tree-height or some other words denoting their actual meaning?


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Stefan Monnier]

> What is α?  What is β?

> Wouldn't have it been better to name those variables number-of-rows
> or tree-height or some other words denoting their actual meaning?

Usually, within the context where the mathematical formula is used,
these variables *are* names denoting their meaning.  These depend on
notational conventions used within specific communities (and usually not
formalized), but they are convenient.  So instead of

    has_type env exp type

you say

    Γ ⊢ e : τ

and it is just as explicit, because τ does mean "a type", and Γ means "a
type environment", and ":" means "has type", and "⊢" means "based on
hypotheses such and such".  Some of those letters/signs have meaning
shared within a fairly large mathematical community while others are
much more specific to a specialized subfield.

Of course, if you're not familiar with the local conventions, it looks
like line noise, but otherwise it offers people much higher concision,
so they can focus on the important aspects.


        Stefan

Re: if vs. when vs. and: style question

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What is α?  What is β?
>
>> Wouldn't have it been better to name those variables number-of-rows
>> or tree-height or some other words denoting their actual meaning?
>
> Usually, within the context where the mathematical formula is used,
> these variables *are* names denoting their meaning.  These depend on
> notational conventions used within specific communities (and usually not
> formalized), but they are convenient.  So instead of
>
>     has_type env exp type
>
> you say
>
>     Γ ⊢ e : τ
>
> and it is just as explicit, because τ does mean "a type", and Γ means "a
> type environment", and ":" means "has type", and "⊢" means "based on
> hypotheses such and such".  Some of those letters/signs have meaning
> shared within a fairly large mathematical community while others are
> much more specific to a specialized subfield.

Math textbooks teaching the same matter usually start with a table of
symbols, with subtle and capricious differences from one book to
another. :-)

> Of course, if you're not familiar with the local conventions, it looks
> like line noise, but otherwise it offers people much higher concision,
> so they can focus on the important aspects.

Those conventions make sense when you work on the same field for long
enough periods (students, specialized programmers...) but I guess that
most of us deal with heterogeneous code on a regular basis. Heck, we do
use different programming languages on the same session. After the end
of the day (or week) when you worked on code dealing with finance,
graphics, databases, concurrency, the Emacs redisplay, generic
algorithms (sorting, etc) and what-not, then you do realize how
counterproductive is to rely on non-obvious local conventions.

As for the higher concision, it is acceptable for cases where the
"read-time"/"think-time" ratio is low (say 15 minutes thinking for each
minute reading) but for the common "what this code does" case, where
such ratios are unnaceptable and a sign of bad coding, those funny
symbols just add cognitive strain.

Re: if vs. when vs. and: style question

[Stefan Monnier]

> Those conventions make sense when you work on the same field for long
> enough periods (students, specialized programmers...) but I guess that
> most of us deal with heterogeneous code on a regular basis. Heck, we do

I was talking about math, not code.
Of course, in cases like Coq and Agda, the overlap between the two can
be significant, so there's a commensurately strong pressure to make sure
the code follows the same notation as the math, to make it easier to
relate the two (which is often crucial, since the code is the one
that's mechanically checked to convince one that the math is right).


        Stefan

Re: if vs. when vs. and: style question

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Mar 30, 2015 at 03:33:41AM +0200, Óscar Fuentes wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:

[...]

> > you say
> >
> >     Γ ⊢ e : τ

[...]

> > Of course, if you're not familiar with the local conventions, it looks
> > like line noise, but otherwise it offers people much higher concision,
> > so they can focus on the important aspects.
> 
> Those conventions make sense when you work on the same field for long
> enough periods (students, specialized programmers...) but I guess that
> most of us deal with heterogeneous code on a regular basis [...]

> As for the higher concision, it is acceptable for cases where the
> "read-time"/"think-time" ratio is low [...]

Excuse you both my selective quoting. But you're just confirming one fear
I had all along: in our trade (hacking) it seems we spend far too much time
coding and far too little time thinking!

Mathematicians, who think more and tinker less, seem to have found a sweet
spot in a far more compact notation.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlUZGwAACgkQBcgs9XrR2kZf1ACeOXndRSR1WfavvlZYWVVXp+pl
vY8AnAq0IXbfAtap8vgiR3brqRWEIKvo
=O1fE
-----END PGP SIGNATURE-----

Re: if vs. when vs. and: style question

[Óscar Fuentes]

<tomas@tuxteam.de> writes:

> On Mon, Mar 30, 2015 at 03:33:41AM +0200, Óscar Fuentes wrote:
>> Those conventions make sense when you work on the same field for long
>> enough periods (students, specialized programmers...) but I guess that
>> most of us deal with heterogeneous code on a regular basis [...]
>
>> As for the higher concision, it is acceptable for cases where the
>> "read-time"/"think-time" ratio is low [...]
>
> Excuse you both my selective quoting. But you're just confirming one fear
> I had all along: in our trade (hacking) it seems we spend far too much time
> coding and far too little time thinking!

Just to be more specific: if a hacker devotes much more time to thinking
that to read and write code while he works on one of those mundane tasks
that makes the 99% of the world's programmer's job, something is wrong
with how he works. Maybe he is doing design (or even requirements
analysis) while he codes, or do not understands the problem domain, or
simply he is in a mess due to previous mistakes...

> Mathematicians, who think more and tinker less, seem to have found a sweet
> spot in a far more compact notation.

Do you know any Mathematician that is paid by the hour? ;-)

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Do you know any Mathematician that is paid by the hour? ;-)

Or that is forced to use differential geometry to solve his problem,
whatever it is, because the enterprises only has other specialists of
differential geometry, and they are easy to find for hiring.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Stefan Monnier]

>> Do you know any Mathematician that is paid by the hour? ;-)
> Or that is forced to use differential geometry to solve his problem,
> whatever it is, because the enterprises only has other specialists of
> differential geometry, and they are easy to find for hiring.

Along the same lines, I don't know many programmers whose code is never
passed to a compiler/interpreter but is instead only read by other
human beings.


        Stefan

Re: if vs. when vs. and: style question

[Marcin Borkowski]

Hello,

first of all: I stand in awe watching this discussion I've inadvertently
started.

On 2015-03-30, at 16:18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> Do you know any Mathematician that is paid by the hour? ;-)
>> Or that is forced to use differential geometry to solve his problem,
>> whatever it is, because the enterprises only has other specialists of
>> differential geometry, and they are easy to find for hiring.
>
> Along the same lines, I don't know many programmers whose code is never
> passed to a compiler/interpreter but is instead only read by other
> human beings.

BTW: I think you nailed a serious problem with contemporary mathematics:
that machine checking proofs isn't a routine part of the publishing
process.  The number of erroneous papers in math journals is
horrifying.  Substantial portion of my depatment's seminar is devoted to
discussing errors in papers.  Once a colleague found a relatively simple
/counterexample/ to a theorem which was a cornerstone of a whole theory
(and a basis for several dozen other papers).

>         Stefan

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: if vs. when vs. and: style question

[Óscar Fuentes]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

>> Along the same lines, I don't know many programmers whose code is never
>> passed to a compiler/interpreter but is instead only read by other
>> human beings.
>
> BTW: I think you nailed a serious problem with contemporary mathematics:
> that machine checking proofs isn't a routine part of the publishing
> process.  The number of erroneous papers in math journals is
> horrifying.  Substantial portion of my depatment's seminar is devoted to
> discussing errors in papers.  Once a colleague found a relatively simple
> /counterexample/ to a theorem which was a cornerstone of a whole theory
> (and a basis for several dozen other papers).

Yeah, that remembers me of Vladimir Voevodsky's story about why he
always has a Coq session running nearby.

OTOH I'm afraid that proof assistants can be a hindrance for creative
work.

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>>> Along the same lines, I don't know many programmers whose code is never
>>> passed to a compiler/interpreter but is instead only read by other
>>> human beings.
>>
>> BTW: I think you nailed a serious problem with contemporary mathematics:
>> that machine checking proofs isn't a routine part of the publishing
>> process.  The number of erroneous papers in math journals is
>> horrifying.  Substantial portion of my depatment's seminar is devoted to
>> discussing errors in papers.  Once a colleague found a relatively simple
>> /counterexample/ to a theorem which was a cornerstone of a whole theory
>> (and a basis for several dozen other papers).

Perhaps it's not pertinent in a specific case, but I'd see it as much as
a question of what axioms or inference rules would be needed to prevent
those counter examples, and thus validate the theory developed so far,
as the need to revise the validity of that theorem and its supposed
consequences.



> Yeah, that remembers me of Vladimir Voevodsky's story about why he
> always has a Coq session running nearby.
>
> OTOH I'm afraid that proof assistants can be a hindrance for creative
> work.


Perhaps they should work both way:  

- deduce consequences from axioms (or check deductions), and

- find axioms and deduction rules that would allow a given "chain of
  reasoning" to be a theorem.


If you only knew Euclidian geometry and imagined a triangle whose sum of
angles was 200 degree, you'd want a formal tool to help you infer
spherical geometry's axioms.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Reality and Proofs (was if vs. when vs. and: style question)

[Rusi]

On Monday, March 30, 2015 at 8:51:47 PM UTC+5:30, Marcin Borkowski wrote:
> Hello,
> 
> first of all: I stand in awe watching this discussion I've inadvertently
> started.

Yes the commission of elders is deliberating on the right scale and form
of punishment for this misdemeanor <wink>

> 
> On 2015-03-30, at 16:18, Stefan Monnier  wrote:
> 
> >>> Do you know any Mathematician that is paid by the hour? ;-)
> >> Or that is forced to use differential geometry to solve his problem,
> >> whatever it is, because the enterprises only has other specialists of
> >> differential geometry, and they are easy to find for hiring.
> >
> > Along the same lines, I don't know many programmers whose code is never
> > passed to a compiler/interpreter but is instead only read by other
> > human beings.
> 
> BTW: I think you nailed a serious problem with contemporary mathematics:
> that machine checking proofs isn't a routine part of the publishing
> process.  The number of erroneous papers in math journals is
> horrifying.  Substantial portion of my depatment's seminar is devoted to
> discussing errors in papers.  Once a colleague found a relatively simple
> /counterexample/ to a theorem which was a cornerstone of a whole theory
> (and a basis for several dozen other papers).

Thomas Kuhn points out that scientific paradigms not only shift slowly with
time, they may actually be incommensurable.
So Galileo was wrong and the pope/ecumenical council were right in punishing
Galileo for his ideas because the earth was *by definition* immovable.

IOW we have a different earth today than they had.

Likewise proofs/truth etc changed dramatically from Aristotle/Euclid to Galileo/Descartes/Newton and once again has seen vast changes post the computer era.

Some recent thoughts collected on that subject
http://blog.languager.org/2015/03/cs-history-0.html

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

<tomas@tuxteam.de> writes:

> On Mon, Mar 30, 2015 at 03:33:41AM +0200, Óscar Fuentes wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> [...]
>
>> > you say
>> >
>> >     Γ ⊢ e : τ
>
> [...]
>
>> > Of course, if you're not familiar with the local conventions, it looks
>> > like line noise, but otherwise it offers people much higher concision,
>> > so they can focus on the important aspects.
>> 
>> Those conventions make sense when you work on the same field for long
>> enough periods (students, specialized programmers...) but I guess that
>> most of us deal with heterogeneous code on a regular basis [...]
>
>> As for the higher concision, it is acceptable for cases where the
>> "read-time"/"think-time" ratio is low [...]
>
> Excuse you both my selective quoting. But you're just confirming one fear
> I had all along: in our trade (hacking) it seems we spend far too much time
> coding and far too little time thinking!
>
> Mathematicians, who think more and tinker less, seem to have found a sweet
> spot in a far more compact notation.

Well, I think the difference is that programmers can deal (or at least,
try to deal) with multi-million-line programs, while mathematicians seem
to snob multi-million-line profs.

http://www.newscientist.com/article/dn26753-mathematicians-anger-over-his-unread-500page-proof.html

On the other hand, some programs are not read and checked enough, as
several security bugs discovered recently showed.

But nonetheless, professionnally, programmers have to work on big code
bases, and find ways to do it, how imperfectly they may be.

It looks like mathematicians are less willing or able to do so.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Rusi]

On Sunday, March 29, 2015 at 7:36:17 PM UTC+5:30, Óscar Fuentes wrote:
> Rusi  writes:
> 
> [snip]
> 
> > And even Elisp!
> >
> > *** Welcome to IELM ***  Type (describe-mode) for help.
> > ELISP> (setq α 1 β 2 γ 3)
> > 3 (#o3, #x3, ?\C-c)
> > ELISP> (list α β γ)
> > (1 2 3)
> 
> Some months ago I experimented with using Unicode on my coding. I was
> very excited about it. At the end, the experience showed without a doubt
> that it is a bad idea. One of the reasons is very familiar to us: a
> funtamental feature of a programmer's font is how clearly it
> distinguishes 1 from l, 0 from O. Using Unicode makes this problem
> explode.
> 

Thank you Oscar for some (rather rare) reasonable argument.

[Compared to yours much of the rest I see here is on the lines:
"Since my keyboard is broken; kindly allow me to break yours!"


As I pointed out earlier what you point out is true and considerably worse than that:
http://en.wikipedia.org/wiki/IDN_homograph_attack


The point is that this choice has already been made: many languages are already
*carelessly* accepting unicode.

Some are a little more laissez-faire than others:
1. "flag" and "flag" are the same identifier in python; but different in 
haskell and elisp.  IMHO python has made the more sane choice

2. Haskell and Elisp accept x₁ , Python doesn't. I think python is wrong here

3. Haskell allows → for -> ← for <- (very heavily used in haskell)
However the symbol that defines its very identity and is its logo – λ –
it does not allow because its in letter category.

> > ELISP> 
> >
> > How much costly was that α to type than alpha?? One backslash!!
> >
> > Add to that the fact that programs are read
> > - 10 times more than written during development
> > - 100 times more during maintenance
> 
> Precisely, my experience is that Unicode makes things much harder to
> read, and not ony because the problem mentioned above.

You are raising a point about a certain software/hardware that we all use and
that no one understands – our brains. Consider:

APL is generally regarded as unreadable. [That it is often derisively called
'writeonly' not unwriteable is a separate discussion]

But neither is Cobol regarded as readable. And worst of all is machine-language.

If an arbitrarily restricted charset were a good fit to our brains, Cobol, which
expressly tries to mirror layman prose (ie stay within [A-Za-z0-9] ) would have 
worked better. And while our machines seem mighty pleased with building the 
universe from {0,1}, our brains (ok at least mine) suffers on reading 
machine-code.

So where on the spectrum between APL/conventional laissez-faire math and
Cobol/Machine-code is the optimum?

I believe this is an open question

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 8:11:23 PM UTC+5:30, Stefan Monnier wrote:
> > For 50 years CS has been living in the impoverished world of ASCII.
> > This makes people think CS and math are more far apart than they
> > essentially/really are.
> 
> You might like to take a look at the Agda language,

Yeah I know about
1. Agda... a bit overboard maybe?? but in the right direction
2. Fortress
3. Julia
4. Haskell (ghc) itself has a unicode extensions flag
   after which we can write the rhses instead of the lhses
=> ⇒
forall ∀
<- →
-> ←
-<< ⤛
>>- ⤜
Ironically the page where this is documented
https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/syntax-extns.html
the last two dont work (show) because the html is charset=ISO-8859-1   :-)
I guess unicode is a moving target...

5. And the mother of all -- APL

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Rusi <rustompmody@gmail.com> writes:

> On Wednesday, March 25, 2015 at 8:11:23 PM UTC+5:30, Stefan Monnier wrote:
>> > For 50 years CS has been living in the impoverished world of ASCII.
>> > This makes people think CS and math are more far apart than they
>> > essentially/really are.
>> 
>> You might like to take a look at the Agda language,
>
> Yeah I know about
> 1. Agda... a bit overboard maybe?? but in the right direction
> 2. Fortress
> 3. Julia
> 4. Haskell (ghc) itself has a unicode extensions flag
>    after which we can write the rhses instead of the lhses
> => ⇒
> forall ∀
> <- →
> -> ←
> -<< ⤛
>>>- ⤜
Notice, that I asked the reader to compare the ease of input.

=>  super easy, two keys to type.
The unicode correspondance?  I would start typing C-x 8 RET double TAB
and not find it in the list. 

So I would have to launch clisp, 
   
   C-- slime RET clisp RET 

wait for it to boot then type:

   (lschar :name "RIGHT_ARROW") RET

the search for double, and not find it, then copy and paste it from your
message,

   (char-name #\⇒)

obtain the character name as "RIGHTWARDS_DOUBLE_ARROW", then type

   C-x 8 RET rightward double arrow RET

which, even if I had know it from the start, is still much more
difficult to type than just =>.




> Ironically the page where this is documented
> https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/syntax-extns.html
> the last two dont work (show) because the html is charset=ISO-8859-1   :-)
> I guess unicode is a moving target...
>
> 5. And the mother of all -- APL

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

RE: if vs. when vs. and: style question

[Drew Adams]

> Notice, that I asked the reader to compare the ease of input.

Before I comment further, let me say that I agree with your point.

> =>  super easy, two keys to type.
> The unicode correspondance?  I would start typing C-x 8 RET double TAB
> and not find it in the list.  So I would have to launch clisp,
>    C-- slime RET clisp RET
> wait for it to boot then type:
>    (lschar :name "RIGHT_ARROW") RET
> the search for double, and not find it, then copy and paste it from your
> message, 
>    (char-name #\⇒)
> obtain the character name as "RIGHTWARDS_DOUBLE_ARROW", then type
>    C-x 8 RET rightward double arrow RET
> which, even if I had know it from the start, is still much more
> difficult to type than just =>.

Yes and no.  Yes, if you haven't used a particular Unicode char
before or use it rarely.  No, if you use it often.

If you use a particular Unicode character often, just give its
insertion a command and bind that to a key.  If you have 30 such
chars, put them all on a prefix key.  Or use completion on their
command names (names you created, so easy for you to type, remember,
complete to,...).

IOW, it's not a big deal to insert Unicode characters, especially
if you insert the same ones over and over.  You do not need to use
`C-x 8 RET' each time.

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 9:36:37 PM UTC+5:30, Drew Adams wrote:
> > Notice, that I asked the reader to compare the ease of input.
> 
> Before I comment further, let me say that I agree with your point.
> 
> > =>  super easy, two keys to type.
> > The unicode correspondance?  I would start typing C-x 8 RET double TAB
> > and not find it in the list.  So I would have to launch clisp,
> >    C-- slime RET clisp RET
> > wait for it to boot then type:
> >    (lschar :name "RIGHT_ARROW") RET
> > the search for double, and not find it, then copy and paste it from your
> > message, 
> >    (char-name #\=>)
> > obtain the character name as "RIGHTWARDS_DOUBLE_ARROW", then type
> >    C-x 8 RET rightward double arrow RET
> > which, even if I had know it from the start, is still much more
> > difficult to type than just =>.
> 
> Yes and no.  Yes, if you haven't used a particular Unicode char
> before or use it rarely.  No, if you use it often.
> 
> If you use a particular Unicode character often, just give its
> insertion a command and bind that to a key.  If you have 30 such
> chars, put them all on a prefix key.  Or use completion on their
> command names (names you created, so easy for you to type, remember,
> complete to,...).
> 
> IOW, it's not a big deal to insert Unicode characters, especially
> if you insert the same ones over and over.  You do not need to use
> `C-x 8 RET' each time.

You get the point better Drew -- thanks!
ASCII (7-bit) is roughly 100 chars
Full (currently defined) Unicode is 100,000 chars

Choosing to go beyond ASCII does not imply an XOR: 100 or 100,000 and nothing else!!
One can choose one's preferred subset with varying degrees of 'accessibility'

In particular for the char => 
I have https://github.com/rrthomas/pointless-xcompose
installed
After that
=> is 3 chars  "M=>" (M is the menu ie compose key)

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 9:49:30 PM UTC+5:30, Rusi wrote:
> On Wednesday, March 25, 2015 at 9:36:37 PM UTC+5:30, Drew Adams wrote:
> > > Notice, that I asked the reader to compare the ease of input.
> > 
> > Before I comment further, let me say that I agree with your point.
> > 
> > > =>  super easy, two keys to type.
> > > The unicode correspondance?  I would start typing C-x 8 RET double TAB
> > > and not find it in the list.  So I would have to launch clisp,
> > >    C-- slime RET clisp RET
> > > wait for it to boot then type:
> > >    (lschar :name "RIGHT_ARROW") RET
> > > the search for double, and not find it, then copy and paste it from your
> > > message, 
> > >    (char-name #\=>)
> > > obtain the character name as "RIGHTWARDS_DOUBLE_ARROW", then type
> > >    C-x 8 RET rightward double arrow RET
> > > which, even if I had know it from the start, is still much more
> > > difficult to type than just =>.
> > 
> > Yes and no.  Yes, if you haven't used a particular Unicode char
> > before or use it rarely.  No, if you use it often.
> > 
> > If you use a particular Unicode character often, just give its
> > insertion a command and bind that to a key.  If you have 30 such
> > chars, put them all on a prefix key.  Or use completion on their
> > command names (names you created, so easy for you to type, remember,
> > complete to,...).
> > 
> > IOW, it's not a big deal to insert Unicode characters, especially
> > if you insert the same ones over and over.  You do not need to use
> > `C-x 8 RET' each time.
> 
> You get the point better Drew -- thanks!
> ASCII (7-bit) is roughly 100 chars
> Full (currently defined) Unicode is 100,000 chars
> 
> Choosing to go beyond ASCII does not imply an XOR: 100 or 100,000 and nothing else!!
> One can choose one's preferred subset with varying degrees of 'accessibility'
> 
> In particular for the char => 
> I have https://github.com/rrthomas/pointless-xcompose
> installed
> After that
> => is 3 chars  "M=>" (M is the menu ie compose key)

Ha! Messed up in transit!
[Some will say that proves the folly of going beyond ASCII]
That => was supposed to be ⇒

ie I meant to say
⇒ is typed by the 3 chars Menu, =, >

रुसि to make sure it stays UTF-8 this time!!

Re: if vs. when vs. and: style question

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> You get the point better Drew -- thanks!
> ASCII (7-bit) is roughly 100 chars Full (currently
> defined) Unicode is 100,000 chars

It is not about the number of chars because the chars
are not used iconographically. That is Sumer 5000
years ago. There were reasons paleo-men stopped doing
that. They should be very proud of what they did and
their aku-aku's are probably shaking their heads in
complete disbelief at your efforts trying to rollback
their achievement.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Dan Espen]

Drew Adams <drew.adams@oracle.com> writes:

>> Notice, that I asked the reader to compare the ease of input.
>
> Before I comment further, let me say that I agree with your point.
>
>> =>  super easy, two keys to type.
>> The unicode correspondance?  I would start typing C-x 8 RET double TAB
>> and not find it in the list.  So I would have to launch clisp,
>>    C-- slime RET clisp RET
>> wait for it to boot then type:
>>    (lschar :name "RIGHT_ARROW") RET
>> the search for double, and not find it, then copy and paste it from your
>> message, 
>>    (char-name #\⇒)
>> obtain the character name as "RIGHTWARDS_DOUBLE_ARROW", then type
>>    C-x 8 RET rightward double arrow RET
>> which, even if I had know it from the start, is still much more
>> difficult to type than just =>.
>
> Yes and no.  Yes, if you haven't used a particular Unicode char
> before or use it rarely.  No, if you use it often.
>
> If you use a particular Unicode character often, just give its
> insertion a command and bind that to a key.  If you have 30 such
> chars, put them all on a prefix key.  Or use completion on their
> command names (names you created, so easy for you to type, remember,
> complete to,...).
>
> IOW, it's not a big deal to insert Unicode characters, especially
> if you insert the same ones over and over.  You do not need to use
> `C-x 8 RET' each time.

Sorry, that scales up for more than 1 or 2 characters how?

I already have a little piece of oak tag paper that I've cut out
to surround the 6-key pad above the arrow keys.
The paper has the legend:

           UNDO
FRONT OPEN AGAIN
    -keys-
           COPY

Yep, even for 5 specially assigned keys, my mind sometimes goes
blank and I look at the paper.

A normal keyboard just isn't designed for a bunch of strange
characters.

Another poster described the issue well.
If we used some other kind of input device, those characters
might be a good idea.  Until then, not so much.

-- 
Dan Espen

RE: if vs. when vs. and: style question

[Drew Adams]

> > If you use a particular Unicode character often, just give its
> > insertion a command and bind that to a key.  If you have 30 such
> > chars, put them all on a prefix key.  Or use completion on their
> > command names (names you created, so easy for you to type, remember,
> > complete to,...).
> >
> > IOW, it's not a big deal to insert Unicode characters, especially
> > if you insert the same ones over and over.  You do not need to use
> > `C-x 8 RET' each time.
> 
> Sorry, that scales up for more than 1 or 2 characters how?

Well, I doubt that I can convince you.  I can only repeat what I
suggested.

There is a big difference, I think, between (1) using `C-x 8 RET'
to complete against zillions of character names (or code points) that
you might not be familiar with and (2) completing against a relative
few (5? 10? 50? 150?) char-command names that you yourself came up with.

My point is that if someone uses relatively few - which, depending on
the person, could be 5 or 500 (or 5000?) chars, then it can make sense
to put their insertion on keys (commands).

> I already have a little piece of oak tag paper that I've cut out
> to surround the 6-key pad above the arrow keys.
> The paper has the legend:
> 
>            UNDO
> FRONT OPEN AGAIN
>     -keys-
>            COPY
> 
> Yep, even for 5 specially assigned keys, my mind sometimes goes
> blank and I look at the paper.

Hey, my mind goes blank too.  But instead of paper I use completion.
IOW, I ask Emacs for help.

> A normal keyboard just isn't designed for a bunch of strange
> characters.

Maybe so.  But if you use the euro character a *lot*, for example,
then you might just consider assigning it a key.  Rather than using
`C-x 8 RET euro sign RET' each time to insert it.

It's also possible to have a command that, in effect, switches to
a keymap that treats your American keyboard as a French one or
whatever, just by changing the relevant key bindings.  Is that
useful for someone?  Maybe; dunno.

> Another poster described the issue well.
> If we used some other kind of input device, those characters
> might be a good idea.  Until then, not so much.

Given a particular physical keyboard, it's a tradeoff (i.e. choice)
wrt which keys do what.  Certainly it is true that the keys of a
typical American keyboard are used a lot in programming languages,
so someone who programs is likely to want to keep those keys bound
to the self-inserting chars they default to.  Such a programmer
probably needs `$' on a key, and isn't about to replace it with a
euro symbol.

But beyond that, it can make sense for someone to assign relatively
easy key sequences to insertion of frequently used Unicode chars.
It all depends on what you need, what you use Emacs for.

If you use lots of Greek chars, but mixed in with mostly ASCII or
Latin 1 chars, then it might make sense for you to assign simple
key sequences to Greek chars.  If you write *mostly* Greek then you
might want to use a Greek keyboard or remap the keys of a non-Greek
keyboard to Greek chars.

FWIW, I think that my library `ucs-cmds.el' can help in the former
case.  You can quickly define commands that insert specific chars,
by specifying a Unicode range etc.
(http://www.emacswiki.org/emacs/download/ucs-cmds.el)

This macro call creates an insertion command for each Greek letter:
(ucsc-make-commands "^greek [a-z]+ letter")

That's 330 commands (330 chars).  Here are the commands for the
letter epsilon, for example:
                                           
greek-capital-letter-epsilon                                            
greek-capital-letter-epsilon-tonos                                      
greek-capital-letter-epsilon-with-dasia                                 
greek-capital-letter-epsilon-with-dasia-and-oxia                        
greek-capital-letter-epsilon-with-dasia-and-varia                       
greek-capital-letter-epsilon-with-oxia                                  
greek-capital-letter-epsilon-with-psili                                 
greek-capital-letter-epsilon-with-psili-and-oxia                        
greek-capital-letter-epsilon-with-psili-and-varia                       
greek-capital-letter-epsilon-with-varia                                 
            
The command names are the Unicode char names, with hyphens instead
of spaces, and lowercase instead of uppercase.

You can of course create shorter aliases, if you like, and use
completion with `M-x'.  And you can assign the 20 or 50 Greek
chars that you use most often to short key sequences.  Or you can
put a bunch of the commands (or all 330) on a prefix key, say
`C-M-g'.  (And nothing requires you to create a command for each
of the 330 Unicode Greek chars.  It's easy to define just the
commands you need.)

It's all about what you need.  If you don't need to insert Unicode
chars, then "Circulez ; il n'y a rien a voir."

As for opening the floodgates to the use of Unicode in programming
code, I don't see that as a problem, one way or the other, wrt
user-defined names.

On the other hand, if you use a language that *requires* you to use
Unicode chars that are hard for you to input, then I'd suggest that
you either try something like the above (e.g., type `=>' to get the
arrow char you want) or you change languages. ;-)

Re: if vs. when vs. and: style question

[Dan Espen]

Drew Adams <drew.adams@oracle.com> writes:

>> > If you use a particular Unicode character often, just give its
>> > insertion a command and bind that to a key.  If you have 30 such
>> > chars, put them all on a prefix key.  Or use completion on their
>> > command names (names you created, so easy for you to type, remember,
>> > complete to,...).
>> >
>> > IOW, it's not a big deal to insert Unicode characters, especially
>> > if you insert the same ones over and over.  You do not need to use
>> > `C-x 8 RET' each time.
>> 
>> Sorry, that scales up for more than 1 or 2 characters how?
>
> Well, I doubt that I can convince you.  I can only repeat what I
> suggested.

My mind is made up, but interesting info like how to type Greek
are one reason why I commented at all.  I think keyboards and
keys are an important issue and the current state of the art falls
far short.  Some important keys are completely missing.
I have no idea why HELP, UNDO, COPY, PASTE, REDO, MINIMIZE,
SCREEN LOCK, etc.
are completely MIA.
Other keys just gather dust.  (SysRq, Scroll Lock, Pause/Break,
KP_/, KP_*
What are these designers thinking.

> There is a big difference, I think, between (1) using `C-x 8 RET'
> to complete against zillions of character names (or code points) that
> you might not be familiar with and (2) completing against a relative
> few (5? 10? 50? 150?) char-command names that you yourself came up with.
>
> My point is that if someone uses relatively few - which, depending on
> the person, could be 5 or 500 (or 5000?) chars, then it can make sense
> to put their insertion on keys (commands).

That's why I asked how many additional characters are proposed for
lets say Python.  More than a few would be a problem.
I put the not sign (¬) on shifted backspace and
still look in my xmodmap file to remember where it is.

>> I already have a little piece of oak tag paper that I've cut out
>> to surround the 6-key pad above the arrow keys.
>> The paper has the legend:
>> 
>>            UNDO
>> FRONT OPEN AGAIN
>>     -keys-
>>            COPY
>> 
>> Yep, even for 5 specially assigned keys, my mind sometimes goes
>> blank and I look at the paper.
>
> Hey, my mind goes blank too.  But instead of paper I use completion.
> IOW, I ask Emacs for help.

A few of those keys above are for the window manager.
Emacs completion doesn't help.

>> A normal keyboard just isn't designed for a bunch of strange
>> characters.
>
> Maybe so.  But if you use the euro character a *lot*, for example,
> then you might just consider assigning it a key.  Rather than using
> `C-x 8 RET euro sign RET' each time to insert it.

I'd rather not need the additional characters.

-- 
Dan Espen

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

Dan Espen writes:

 > My mind is made up, but interesting info like how to type Greek
 > are one reason why I commented at all.  I think keyboards and
 > keys are an important issue and the current state of the art falls
 > far short.  Some important keys are completely missing.

There are factories producing keyboards with cherry switches and two or
three rows of "L(num)" keys on the right side. They are backlit and some
models have customizable light color.

 > I have no idea why HELP, UNDO, COPY, PASTE, REDO, MINIMIZE,
 > SCREEN LOCK, etc.

I think that these keys can be used for these functions. Many of them
are not GNU/Linux friendly.

 > >> I already have a little piece of oak tag paper that I've cut out
 > >> to surround the 6-key pad above the arrow keys.
 > >> The paper has the legend:
 > >> 
 > >>            UNDO
 > >> FRONT OPEN AGAIN
 > >>     -keys-
 > >>            COPY

There are companies creating keyboards with custom keycolors and mainly
custom key labels - i have Ctrl, Super and Meta on the low left corner
of mine.

 > > Maybe so.  But if you use the euro character a *lot*, for example,
 > > then you might just consider assigning it a key.  Rather than using
 > > `C-x 8 RET euro sign RET' each time to insert it.

You usually use composing or alt-5 for that.

There is one point pro the use of "more than the ASCII set" in a
source code.

Take the example of a code-grinder-written kind of program, and
consider code-grinders that are not native English speakers.

Let's assume that our code-grinder is a native Italian (or French,
Spanish or German) speaker and he is not used to English. Or the
project leader does want symbols (i.e. variable names) being in
the mother tongue of the coders.

In Italian "amount" translates with "quantità", but more than often
the symbol will be something like "quantita" due to the restriction to
pure ASCII. No matter what the brain of the coder will feel that
"quantita" is wrong, he will get used to it. But I think that is much
better to have a symbol written in a language the coder is able to use
for thinking.

Just my 2 cents.

And thanks to all who pointed out the subtle differences between
if, when, unless.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"
	 Lisp illiterate.
	 
Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

"Gian Uberto Lauri" <saint@eng.it> writes:

> Dan Espen writes:
>
>  > My mind is made up, but interesting info like how to type Greek
>  > are one reason why I commented at all.  I think keyboards and
>  > keys are an important issue and the current state of the art falls
>  > far short.  Some important keys are completely missing.
>
> There are factories producing keyboards with cherry switches and two or
> three rows of "L(num)" keys on the right side. They are backlit and some
> models have customizable light color.

If you go the keyboard way, then what you want is an Optimus Maximus
keyboard.
http://www.artlebedev.com/everything/optimus/maximus/

> There is one point pro the use of "more than the ASCII set" in a
> source code.
>
> Take the example of a code-grinder-written kind of program, and
> consider code-grinders that are not native English speakers.
>
> Let's assume that our code-grinder is a native Italian (or French,
> Spanish or German) speaker and he is not used to English. Or the
> project leader does want symbols (i.e. variable names) being in
> the mother tongue of the coders.
>
> In Italian "amount" translates with "quantità", but more than often
> the symbol will be something like "quantita" due to the restriction to
> pure ASCII. No matter what the brain of the coder will feel that
> "quantita" is wrong, he will get used to it. But I think that is much
> better to have a symbol written in a language the coder is able to use
> for thinking.
>
> Just my 2 cents.

This 2-cents is what leads to Chinese ideograms.

Not really a progress.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

>> There is one point pro the use of "more than the ASCII set" in a
>> source code.
>>
>> Take the example of a code-grinder-written kind of program, and
>> consider code-grinders that are not native English speakers.
>>
>> Let's assume that our code-grinder is a native Italian (or French,
>> Spanish or German) speaker and he is not used to English. Or the
>> project leader does want symbols (i.e. variable names) being in
>> the mother tongue of the coders.
>>
>> In Italian "amount" translates with "quantità", but more than often
>> the symbol will be something like "quantita" due to the restriction to
>> pure ASCII. No matter what the brain of the coder will feel that
>> "quantita" is wrong, he will get used to it. But I think that is much
>> better to have a symbol written in a language the coder is able to use
>> for thinking.
>>
>> Just my 2 cents.
>
> This 2-cents is what leads to Chinese ideograms.
>
> Not really a progress.

And also, you can already do it, using those same Chinese ideograms.

  数量 = amount = quantità


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Unicode in source (Was Re: if vs. when vs. and: style question)

[Gian Uberto Lauri]

Pascal J. Bourguignon writes:

 > And also, you can already do it,

I knew it.

 > using those same Chinese ideograms.
 > 
 >   数量 = amount = quantità

With LISP macros you could have a fully Chinese domain specific
language.

Why this could be bad?

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: Unicode in source (Was Re: if vs. when vs. and: style question)

[Pascal J. Bourguignon]

"Gian Uberto Lauri" <saint@eng.it> writes:

> Pascal J. Bourguignon writes:
>
>  > And also, you can already do it,
>
> I knew it.
>
>  > using those same Chinese ideograms.
>  > 
>  >   数量 = amount = quantità
>
> With LISP macros you could have a fully Chinese domain specific
> language.
>
> Why this could be bad?

Because it's easier to learn English and easier to type quantity instead
of quantita, than to learn 8000+ ideograms and type one of them.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: Unicode in source (Was Re: if vs. when vs. and: style question)

[Gian Uberto Lauri]

Pascal J. Bourguignon writes:
 > Because it's easier to learn English and easier to type quantity instead
 > of quantita, than to learn 8000+ ideograms and type one of them.

Not an absolute truth, especially if those ideograms are the way your
mother tongue is written, or if you English skills are poor (you can't
think in English) or simply you feel a bit too much colonized by the
English language :).

I admit that most Italian programmer would write qta to save typing ;).

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: Unicode in source (Was Re: if vs. when vs. and: style question)

[Pascal J. Bourguignon]

"Gian Uberto Lauri" <saint@eng.it> writes:

> Pascal J. Bourguignon writes:
>  > Because it's easier to learn English and easier to type quantity instead
>  > of quantita, than to learn 8000+ ideograms and type one of them.
>
> Not an absolute truth, especially if those ideograms are the way your
> mother tongue is written, or if you English skills are poor (you can't
> think in English) or simply you feel a bit too much colonized by the
> English language :).

Granted, but this is a difficult question.

- most programming languages have English keywords and libraries.

- it is difficult for me to constantly switch between languages in
  programs, keywords in English, identifiers and comments in French.

- writing identifiers and comments in a national language makes it more
  difficult for international cooperation.  

  This is not necessarily a point in favor of using English: you may
  want to avoid aliens to have access to your national software.  But if
  you intend to have your startup bought out, or if you're developing
  open source software and expect international cooperation, then you
  will get better results using the international language.

- one could use a programming language based on the national language,
  where writing identifiers and comments inthe national language would
  be natural. (There have been such languages using Chinese, Russian,
  French; recently somebody designed one in Arabic
  http://nas.sr/%D9%82%D9%84%D8%A8/ ). 
  
  But again, with the internet, if you want internationnal cooperation,
  this wouldn't be a good idea.  On the other hand if you want to
  restrict it to your nation, then it's definitely a good idea.


> I admit that most Italian programmer would write qta to save typing ;).

Or we could use Latin or Esperanto, or Interlingua, or Lojban or
https://xkcd.com/927/ 
Damn!


https://news.ycombinator.com/item?id=9270515

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

Pascal J. Bourguignon writes:
 > "Gian Uberto Lauri" <saint@eng.it> writes:
 > 
 > > Dan Espen writes:
 > >
 > >  > My mind is made up, but interesting info like how to type Greek
 > >  > are one reason why I commented at all.  I think keyboards and
 > >  > keys are an important issue and the current state of the art falls
 > >  > far short.  Some important keys are completely missing.
 > >
 > > There are factories producing keyboards with cherry switches and two or
 > > three rows of "L(num)" keys on the right side. They are backlit and some
 > > models have customizable light color.
 > 
 > If you go the keyboard way, then what you want is an Optimus Maximus
 > keyboard.
 > http://www.artlebedev.com/everything/optimus/maximus/

I know it, but it is not mechanical, damn expensive and, AFAIK, not
GNU/Linux friendly.

 > > Just my 2 cents.
 > 
 > This 2-cents is what leads to Chinese ideograms.
 > 
 > Not really a progress.

Not this true. AFAIK Chinese (and Arabs - or at least is true in
Lebanon) do use western keyboard with something that transliterates
back to their alphabet from a western (English) transliteration. It
seems they are prevented from using their own mother tongue at the
hardware level :).

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

> On 26 Mar 2015, at 11:43, Gian Uberto Lauri <saint@eng.it> wrote:
> 
> Pascal J. Bourguignon writes:
>> "Gian Uberto Lauri" <saint@eng.it> writes:
>> 
>>> Dan Espen writes:
>>> 
>>>> My mind is made up, but interesting info like how to type Greek
>>>> are one reason why I commented at all.  I think keyboards and
>>>> keys are an important issue and the current state of the art falls
>>>> far short.  Some important keys are completely missing.
>>> 
>>> There are factories producing keyboards with cherry switches and two or
>>> three rows of "L(num)" keys on the right side. They are backlit and some
>>> models have customizable light color.
>> 
>> If you go the keyboard way, then what you want is an Optimus Maximus
>> keyboard.
>> http://www.artlebedev.com/everything/optimus/maximus/
> 
> I know it, but it is not mechanical, damn expensive and, AFAIK, not
> GNU/Linux friendly.
> 
>>> Just my 2 cents.
>> 
>> This 2-cents is what leads to Chinese ideograms.
>> 
>> Not really a progress.
> 
> Not this true. AFAIK Chinese (and Arabs - or at least is true in
> Lebanon) do use western keyboard with something that transliterates
> back to their alphabet from a western (English) transliteration. It
> seems they are prevented from using their own mother tongue at the
> hardware level :).

Indeed and this is my point.

Alphabet is a great invention.  

The idea that you can build all the words (all the symbols) of the dictionary from a small set if discrete letters by a simple agglutination rule.

Notice that Korean script is alphabetic, syllabes look like ideograms, but they have actually a simple alphabetic basis, which makes it easy to type.  But this script was defined after the invention of the printing press.

Usual mathematic notation is hieroglyfic.  It doesn't need to be.
http://www.infoq.com/presentations/We-Really-Dont-Know-How-To-Compute
http://mitpress.mit.edu/sites/default/files/titles/content/sicm/book.html

-- 
__Pascal J. Bourguignon__

Re: if vs. when vs. and: style question

[Emanuel Berg]

"Gian Uberto Lauri" <saint@eng.it> writes:

> There are companies creating keyboards with custom
> keycolors and mainly custom key labels - i have
> Ctrl, Super and Meta on the low left corner of mine.

There are many companies that produces keyboards that
look like they have been taken straight from
a science fiction movie tho not a too old one as those
keyboards look way cooler. If they'd just get a touch
of wear and tear they'd look awesome, like the cockpit
of a space fighter or intergalactic carrier, if such
exist. I love those lights and dizzy colors, for
example to light a work station so you can cut
firewood even in the evenings and at night.
Especially when it is windy with rain it can get
phsycadelic with your mind to go with it.

But: on keyboards, such colors don't have any function
as no one has to look down anymore and see what keys
they are hitting. Also, those keyboards are
ridiculously expensive, and are consumed by gamers who
don't know squat about computers. They are
status symbols among the kids in the neighborhood who
don't know anything about life and so let such things
get to their minds, endless consumerism, envy, bad
blood...

It is one of the things with computers, unlike for
example those who walk the paths of physics,
chemistry, and such, that with computers you can go
anywhere from very little, while the chemists etc.
can be all the brilliant they want, and sometimes are,
but without the zillion dollar lab they are lucky if
they can use their kitchen sink to blow up their
cat's whiskers.

So, is all the more a sad state that so many young men
get stuck in the gamer limbo, otherwise they could do
amazing things.

I read somewhere that hackers are bitter. I hope I'm
not, but much of what I see makes me sad, let's put it
that way.

> Let's assume that our code-grinder is a native
> Italian (or French, Spanish or German) speaker and
> he is not used to English. Or the project leader
> does want symbols (i.e. variable names) being in the
> mother tongue of the coders. ... In Italian "amount"
> translates with "quantità" ...

The Italian, French, Spanish, and German programmers
are more than capable of coding in English. If they
are not, which they are, they can learn while doing
it, and do while learning it. This will make the
better programmers as well. Source code in any other
language than the old Anglo-American is a dead end for
many reasons, not just the impractical side of it.
Don't do it.

When you write an e-mail to your mother in Genova
asking for a "quantità" of cash to uphold your
good-for-nothing lifestyle, that is another matter.
Of course, then you should be able to use any natural
language, because then it is a matter of human-human
communication - the computer being a medium in between
doesn't change that. Talking with the computer is
another matter and that is done in code, where
variable and function names are in English. Period: .

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Emanuel Berg]

Emanuel Berg <embe8573@student.uu.se> writes:

> The Italian, French, Spanish, and German programmers
> are more than capable of coding in English. If they
> are not, which they are, they can learn while doing
> it, and do while learning it. This will make the
> better programmers as well. Source code in any other
> language than the old Anglo-American is a dead end for
> many reasons, not just the impractical side of it.
> Don't do it.

There are a couple of gray-zones, I just realized.

For example books on computers: should they only be in
English as well?

Well, I think the general trend has been in that
direction for several years and especially with the
degree of specialization that comes with the field.
Soon it will be a de facto situation. But general
textbooks can absolutely be in whatever language, tho
then they must provide the English equivalents of all
lingo - often, there isn't even such a word in the
non-English language, which will make the book choppy,
sometimes, but that's unavoidable. Once I read a book
which was some 1000 pages or close on databases.
That was in Swedish, and I don't think I would have
mustered it if it had been in English, but I'm not
sure. There is also the altruistic side to it. If all
specialists just do epigon works in their own
languages, instead of taking on the entire audience
trying to advance things on a world scale, there will
be much a slower pace of innovation...

As for on-line documentation, for example man pages
and such, those should be in English as they are often
of the reference kind. Nonetheless there have been
translation attempts and the French in particular is
an immense endeavor, but I think that has to do in
part with French pride, and besides that should be
passe anyway as modern-day French programmers have
absolutely no problem doing their stuff in English.

In a way this is a bit sad but in another way it is
for the good, and besides it is reality, so everyone
should just deal with it and move on.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Emanuel Berg]

Dan Espen <despen@verizon.net> writes:

> My mind is made up, but interesting info like how to
> type Greek are one reason why I commented at all.

If discussion was only between people whose minds
weren't made up, there would be a lot less of it.
And people who have their minds made up and discuss
what their minds are made up about are not less likely
to change their minds in the future compared to
anyone else.

> I think keyboards and keys are an important issue

Indeed, pick up a random book om computers or
programming. Chances are they will mention the while
loop and the for loop but it doesn't say how you
should position your body for the most mental-physical
power, or even what keys should be hit by what
fingers, or for that matter anything on the
bio-mechanics of shortcuts and finger habits.

It is *very* strange! Because a kid can understand the
while loop, and many kids do, a kid don't know crap
about self-programming or ergonomics - I didn't know
that people could have consistent pain, suffer from
self-doubt, etc., until I was... actually I don't know
when I realized such things.

> and the current state of the art falls far short.
> Some important keys are completely missing. I have
> no idea why HELP, UNDO, COPY, PASTE, REDO, MINIMIZE,
> SCREEN LOCK, etc. are completely MIA. Other keys
> just gather dust. (SysRq, Scroll Lock, Pause/Break,
> KP_/, KP_* What are these designers thinking.

Good question! But you know how to rewire those to
your liking, so it isn't that bad, is it?

> That's why I asked how many additional characters
> are proposed for lets say Python. More than a few
> would be a problem. I put the not sign (¬) on
> shifted backspace and still look in my xmodmap file
> to remember where it is. ... I'd rather not need the
> additional characters.

If you include but a few, you might as well include
zero and don't have to deal with any
translation/interface overhead getting those few to
work and be portable/communicatable as well.
The Unicode not sing does not turn a bad programmer
into a good one nor a bad program into anything less
bad. Don't do it.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Drew Adams <drew.adams@oracle.com> writes:

> Maybe so.  But if you use the euro character a *lot*, for example,
> then you might just consider assigning it a key.  Rather than using
> `C-x 8 RET euro sign RET' each time to insert it.

Hey!  I did that!

If only I could remember what key I assigned to it!  It's one of the
keys left free by the greek alphabet, I know it's somewhere…

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

RE: if vs. when vs. and: style question

[Drew Adams]

> > Maybe so.  But if you use the euro character a *lot*, for example,
> > then you might just consider assigning it a key.  Rather than using
> > `C-x 8 RET euro sign RET' each time to insert it.
> 
> Hey!  I did that!
> 
> If only I could remember what key I assigned to it!  It's one of the
> keys left free by the greek alphabet, I know it's somewhere…

See the 11th word I wrote.  If you insert that character a *lot*
then (a) you will likely assign it to a quick key and (b) you will
likely remember it.

You remember which key inserts `$', don't you?  If you look at the
keyboard to find `$' *each time* then you can perhaps consider
marking your keyboard with a little `€' for the euro too - meme
combat.

And if the name of the command that inserts it is `euro-insert'
then you can perhaps fall back to `M-x eu TAB RET'.

(Yeah, in the case of the euro sign, `M-x eu TAB RET' is not
a lot better than `C-x 8 RET euro SPC SPC RET'.  But in the
case of GREEK SMALL LETTER EPSILON WITH OXIA it might help
to have a dedicated key, should you happen to use that a lot.)

Re: if vs. when vs. and: style question

[Richard Wordingham]

On Wed, 25 Mar 2015 13:31:22 -0700 (PDT)
Drew Adams <drew.adams@oracle.com> wrote:

> (Yeah, in the case of the euro sign, `M-x eu TAB RET' is not
> a lot better than `C-x 8 RET euro SPC SPC RET'.  But in the
> case of GREEK SMALL LETTER EPSILON WITH OXIA it might help
> to have a dedicated key, should you happen to use that a lot.)

<esc>-x ucs-i<tab><ret>gree<tab>sm<tab>l<tab>ep<tab> w<tab>o<tab>

works quite well if you don't use it very often.  I shall miss the
shorthand of ucs-i when ucs-insert is fully replaced by insert-char.

I switch a lot between UK, Thai, Tai Tham and IPA keyboards (the latter
three defined in Emacs), but I find the abbreviated commands set-i and
toggle-inp much easier for switching keyboards than trying to
remember the various shortcuts.

One of the issues with using the full set of Unicode characters is that
many are easily misread when there are no constraints.  Many Greek
capitals look just like Roman capitals, and Latin 'o', Greek 'ο' and
Cyrillic 'о' may be indistinguishable.  This is not a good idea for
writing code.

Richard.

RE: if vs. when vs. and: style question

[Drew Adams]

> > (Yeah, in the case of the euro sign, `M-x eu TAB RET' is not
> > a lot better than `C-x 8 RET euro SPC SPC RET'.  But in the
> > case of GREEK SMALL LETTER EPSILON WITH OXIA it might help
> > to have a dedicated key, should you happen to use that a lot.)
> 
> <esc>-x ucs-i<tab><ret>gree<tab>sm<tab>l<tab>ep<tab> w<tab>o<tab>
> works quite well if you don't use it very often.

OK.  And C-x 8 RET works the same as ESC x ucs-i TAB RET.  But I
guess your point is that the former is not an easy key sequence to
type.  (The latter is easy, but long.)  In that case, I'd suggest
binding it to something simpler.

> I shall miss the shorthand of ucs-i when ucs-insert is fully replaced
> by insert-char.

Just defalias it yourself: (defalias 'ucs-insert 'insert-char).

> One of the issues with using the full set of Unicode characters is that
> many are easily misread when there are no constraints.  Many Greek
> capitals look just like Roman capitals, and Latin 'o', Greek 'ο' and
> Cyrillic 'о' may be indistinguishable.  This is not a good idea for
> writing code.

+1 for that.

Re: if vs. when vs. and: style question

[Richard Wordingham]

On Wed, 25 Mar 2015 16:21:27 -0700 (PDT)
Drew Adams <drew.adams@oracle.com> wrote:

> > <esc>-x ucs-i<tab><ret>gree<tab>sm<tab>l<tab>ep<tab> w<tab>o<tab>
> > works quite well if you don't use it very often.
> 
> OK.  And C-x 8 RET works the same as ESC x ucs-i TAB RET.  But I
> guess your point is that the former is not an easy key sequence to
> type.

No.  My point is that the long sequence is easier to remember.
Moreover, having typed a long sequence once in an editing session, one
can then retrieve it by command and selection recall (up and own
arrows).

Richard.

Re: if vs. when vs. and: style question

[Rusi]

On Thursday, March 26, 2015 at 4:51:40 AM UTC+5:30, Drew Adams wrote:

> > One of the issues with using the full set of Unicode characters is that
> > many are easily misread when there are no constraints.  Many Greek
> > capitals look just like Roman capitals, and Latin 'o', Greek 'ο' and
> > Cyrillic 'о' may be indistinguishable.  This is not a good idea for
> > writing code.
> 
> +1 for that.

Its worse than just 'misread' giving bugs:
https://en.wikipedia.org/wiki/IDN_homograph_attack

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

Rusi writes:

 > Its worse than just 'misread' giving bugs:
 > https://en.wikipedia.org/wiki/IDN_homograph_attack

This is interesting, but could be solved (for the misread part) at the
lexical analyzer level of a compiler/interpreter, i.e. refusing
strings that contain strings with character that do not belong to the
same (human) alphabet.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[Rusi]

On Thursday, March 26, 2015 at 3:31:59 PM UTC+5:30, Gian Uberto Lauri wrote:
> Rusi writes:
> 
>  > Its worse than just 'misread' giving bugs:
>  > https://en.wikipedia.org/wiki/IDN_homograph_attack
> 
> This is interesting, but could be solved (for the misread part) at the
> lexical analyzer level of a compiler/interpreter, i.e. refusing
> strings that contain strings with character that do not belong to the
> same (human) alphabet.

I guess its important to distinguish two quite different kinds of problem:
a. Stupidity/Carelessness  ⇒  Shoot oneself in foot
b. Malice, Ill-intent, aka criminality

*** Welcome to IELM ***  Type (describe-mode) for help.
ELISP> (setq к 0)
0 (#o0, #x0, ?\C-@)
ELISP> k
*** Eval error ***  Symbol's value as variable is void: k
ELISP> 

[May or may not be obvious depending on fonts that one k is latin the other is
cyrillic ]

Now with at least aehkoptxy being present in Latin and Cyrillic,
just as someone can spoof URLs, probably someone can introduce subtle
'viruses' into source code

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

Rusi writes:

 > *** Welcome to IELM ***  Type (describe-mode) for help.
 > ELISP> (setq к 0)
 > 0 (#o0, #x0, ?\C-@)
 > ELISP> k
 > *** Eval error ***  Symbol's value as variable is void: k

In lisp-interaction-mode works perfectly.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

"Gian Uberto Lauri" <saint@eng.it> writes:

> Rusi writes:
>
>  > *** Welcome to IELM ***  Type (describe-mode) for help.
>  > ELISP> (setq к 0)
>  > 0 (#o0, #x0, ?\C-@)
>  > ELISP> k
>  > *** Eval error ***  Symbol's value as variable is void: k
>
> In lisp-interaction-mode works perfectly.

No, it won't. You missed the point.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1152 bytes --]

1Pascal J. Bourguignon writes:
 > "Gian Uberto Lauri" <saint@eng.it> writes:
 > 
 > > Rusi writes:
 > >
 > >  > *** Welcome to IELM ***  Type (describe-mode) for help.
 > >  > ELISP> (setq к 0)
 > >  > 0 (#o0, #x0, ?\C-@)
 > >  > ELISP> k
 > >  > *** Eval error ***  Symbol's value as variable is void: k
 > >
 > > In lisp-interaction-mode works perfectly.
 > 
 > No, it won't. You missed the point.

OK, misreading on my side, I was not careful enought. I can notice now
the slight difference in the two characters.

I see now that the first is Greek and the second is Latin. I run my
test using always the Greek letter.  But it's perfectly working in the
example Latin-k-symbol has not been defined.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO


[-- Attachment #2: snapshot wit a Latin and a Greek 'kappa'. --]
[-- Type: image/jpeg, Size: 14131 bytes --]

Re: if vs. when vs. and: style question

[Emanuel Berg]

Richard Wordingham <richard.wordingham@ntlworld.com>
writes:

> One of the issues with using the full set of Unicode
> characters is that many are easily misread when
> there are no constraints. Many Greek capitals look
> just like Roman capitals, and Latin 'o', Greek 'ο'
> and Cyrillic 'о' may be indistinguishable. This is
> not a good idea for writing code.

Good point. In addition, there are many Unicode chars
that aren't human language chars but instead are to be
used in geometric figures, in math and otherwise
scientific/engineering notation, and so on - and those
also collide (or almost so) with for example the
Latin 'o' and probably other letters as well.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, April 1, 2015 at 7:57:07 AM UTC+5:30, Emanuel Berg wrote:
> Richard Wordingham writes:
> 
> > One of the issues with using the full set of Unicode
> > characters is that many are easily misread when
> > there are no constraints. Many Greek capitals look
> > just like Roman capitals, and Latin 'o', Greek 'ο'
> > and Cyrillic 'о' may be indistinguishable. This is
> > not a good idea for writing code.
> 
> Good point. In addition, there are many Unicode chars
> that aren't human language chars but instead are to be
> used in geometric figures, in math and otherwise
> scientific/engineering notation, and so on - and those
> also collide (or almost so) with for example the
> Latin 'o' and probably other letters as well.

Of course — Richard does use the phrase "FULL set of Unicode characters"

Currently we see programming languages ALREADY SUPPORTING large swathes of the
1 million chars for identifier-chars -- mostly the 'Letter' and perhaps
the 'number/digit' categories.

So there are two somewhat opposite points:
1. Supporting the Babel of human languages in programming identifiers is
probably a mistake.  In any case if a language must go that way, the choice of
html seems more sane: active opt-in with (something like) a charset declaration
rather than have the whole truckload thrown at someone unsuspecting.
So if a А (cyrillic) and the usual A got mixed up, at the least you asked for it!!

2. The basic 'infrastructure' of a language in C think "; {}()" operators, '#'
the quotes themselves etc is drawn exclusively from ASCII for historical reasons
that are 2015-irrelevant.

Now python (for example) has half a dozen 'quoteds'
- strings "...
- unicode strings u"..."
- triple quoted strings (can contain newlines) """..."""
- raw strings r"..." special chars like backslash are not special
etc 

And the chars like « ‹ seem to be just calling for use

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Rusi <rustompmody@gmail.com> writes:

> On Wednesday, April 1, 2015 at 7:57:07 AM UTC+5:30, Emanuel Berg wrote:
>> Richard Wordingham writes:
>> 
>> > One of the issues with using the full set of Unicode
>> > characters is that many are easily misread when
>> > there are no constraints. Many Greek capitals look
>> > just like Roman capitals, and Latin 'o', Greek 'ο'
>> > and Cyrillic 'о' may be indistinguishable. This is
>> > not a good idea for writing code.
>> 
>> Good point. In addition, there are many Unicode chars
>> that aren't human language chars but instead are to be
>> used in geometric figures, in math and otherwise
>> scientific/engineering notation, and so on - and those
>> also collide (or almost so) with for example the
>> Latin 'o' and probably other letters as well.
>
> Of course — Richard does use the phrase "FULL set of Unicode characters"
>
> Currently we see programming languages ALREADY SUPPORTING large swathes of the
> 1 million chars for identifier-chars -- mostly the 'Letter' and perhaps
> the 'number/digit' categories.

Quick, without looking it up, is: ➒ a digit? a letter? something else?
What about Ⅸ or ๙? Are they digits or letters?

> So there are two somewhat opposite points:
> 1. Supporting the Babel of human languages in programming identifiers is
> probably a mistake.  In any case if a language must go that way, the choice of
> html seems more sane: active opt-in with (something like) a charset declaration
> rather than have the whole truckload thrown at someone unsuspecting.
> So if a А (cyrillic) and the usual A got mixed up, at the least you asked for it!!

Yes, a mandatory declarations could solve some problems.


> 2. The basic 'infrastructure' of a language in C think "; {}()" operators, '#'
> the quotes themselves etc is drawn exclusively from ASCII for historical reasons
> that are 2015-irrelevant.

And have alternatives too: 

> Now python (for example) has half a dozen 'quoteds'
> - strings "...
> - unicode strings u"..."
> - triple quoted strings (can contain newlines) """..."""
> - raw strings r"..." special chars like backslash are not special
> etc 
>
> And the chars like « ‹ seem to be just calling for use

In German, they quote as:     »Hallo«
In French, they quote as:     « Salut ! »
In old books, they quote as:  « One line,
                              « another
                              « final line »

The real problem introduced by unicode, is that not only it has a lot of
complicated rules in itself, but the usage of foreign-language
characters would have to come with the corresponding localized rules
too!

There's no (contemporary) way any sane program can implement them
correctly, much less a program as unrelated to this (international human
language) domain as a programming language compiler.

I don't say once AI will be running on your smartphones (instead of on
Apple, Google or IBM supercomputers), that it won't be possible to have
it deal with that, even in compiler sources.  But not now.  It's too early.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, April 1, 2015 at 8:07:43 PM UTC+5:30, Pascal J. Bourguignon wrote:
> Rusi writes:
> 
> > On Wednesday, April 1, 2015 at 7:57:07 AM UTC+5:30, Emanuel Berg wrote:
> >> Richard Wordingham writes:
> >> 
> >> > One of the issues with using the full set of Unicode
> >> > characters is that many are easily misread when
> >> > there are no constraints. Many Greek capitals look
> >> > just like Roman capitals, and Latin 'o', Greek 'ο'
> >> > and Cyrillic 'о' may be indistinguishable. This is
> >> > not a good idea for writing code.
> >> 
> >> Good point. In addition, there are many Unicode chars
> >> that aren't human language chars but instead are to be
> >> used in geometric figures, in math and otherwise
> >> scientific/engineering notation, and so on - and those
> >> also collide (or almost so) with for example the
> >> Latin 'o' and probably other letters as well.
> >
> > Of course — Richard does use the phrase "FULL set of Unicode characters"
> >
> > Currently we see programming languages ALREADY SUPPORTING large swathes of the
> > 1 million chars for identifier-chars -- mostly the 'Letter' and perhaps
> > the 'number/digit' categories.
> 
> Quick, without looking it up, is: ➒ a digit? a letter? something else?
> What about Ⅸ or ๙? Are they digits or letters?

I guess 1st is
2nd dunno
3rd cant even read :-)

... all of proves what I am saying (as you concede below)

> 
> > So there are two somewhat opposite points:
> > 1. Supporting the Babel of human languages in programming identifiers is
> > probably a mistake.  In any case if a language must go that way, the choice of
> > html seems more sane: active opt-in with (something like) a charset declaration
> > rather than have the whole truckload thrown at someone unsuspecting.
> > So if a А (cyrillic) and the usual A got mixed up, at the least you asked for it!!
> 
> Yes, a mandatory declarations could solve some problems.

Yes…  We need
- Less internationalization
- More universalization

My points in

http://blog.languager.org/2015/01/unicode-and-universe.html
http://blog.languager.org/2015/02/universal-unicode.html

1st is the general idea,
2nd is examples of how more the math more is the good; though it gives
some ideas of other areas of universalization

Re: if vs. when vs. and: style question

[Rusi]

On Thursday, March 26, 2015 at 2:01:45 AM UTC+5:30, Drew Adams wrote:
> > > Maybe so.  But if you use the euro character a *lot*, for example,
> > > then you might just consider assigning it a key.  Rather than using
> > > `C-x 8 RET euro sign RET' each time to insert it.
> > 
> > Hey!  I did that!
> > 
> > If only I could remember what key I assigned to it!  It's one of the
> > keys left free by the greek alphabet, I know it's somewhere...
> 
> See the 11th word I wrote.  If you insert that character a *lot*
> then (a) you will likely assign it to a quick key and (b) you will
> likely remember it.

Ive been trying to explain (starting with myself!) multiple levels of 
input methods, quite along the lines you seem to be suggesting:
http://blog.languager.org/2015/01/unicode-and-universe.html#IMLevels

Additions/corrections welcome!

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Drew Adams <drew.adams@oracle.com> writes:

> On the other hand, if you use a language that *requires* you to use
> Unicode chars that are hard for you to input, then I'd suggest that
> you either try something like the above (e.g., type `=>' to get the
> arrow char you want) or you change languages. ;-)

Definitely, type => to get ⇒.

I've got a few "electric" key bindings like that, for example, when I
type three dots in a sequence, I get …


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Alan Schmitt]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

On 2015-03-25 20:20, "Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Drew Adams <drew.adams@oracle.com> writes:
>
>> On the other hand, if you use a language that *requires* you to use
>> Unicode chars that are hard for you to input, then I'd suggest that
>> you either try something like the above (e.g., type `=>' to get the
>> arrow char you want) or you change languages. ;-)
>
> Definitely, type => to get ⇒.
>
> I've got a few "electric" key bindings like that, for example, when I
> type three dots in a sequence, I get …

I use http://ergoemacs.org/emacs/xmsi-math-symbols-input.html for my
unicode needs, which is easily extended.

Alan

-- 
OpenPGP Key ID : 040D0A3B4ED2E5C7

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: if vs. when vs. and: style question

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> I've got a few "electric" key bindings like that,
> for example, when I type three dots in a sequence,
> I get …

And when you type two "l"s in a row, do you get
a special char inserted for that as well? I'm sure
there is a Unicode char with two parallel vertical
bars. Isn't that an even better idea than the three
dots one, because it appears much more frequently? No?
Why not?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> "Pascal J. Bourguignon" <pjb@informatimago.com>
> writes:
>
>> I've got a few "electric" key bindings like that,
>> for example, when I type three dots in a sequence,
>> I get …
>
> And when you type two "l"s in a row, do you get
> a special char inserted for that as well? I'm sure
> there is a Unicode char with two parallel vertical
> bars. Isn't that an even better idea than the three
> dots one, because it appears much more frequently? No?
> Why not?

It's not a question of typing fast, it's a question of typing easy.
It's easier to type ... to get … 
than to type C-x 8 RET HORIZONTAL ELLIPSIS RET

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Rusi]

On Monday, March 30, 2015 at 8:22:04 AM UTC+5:30, Pascal J. Bourguignon wrote:
> Emanuel Berg writes:
> 
> > "Pascal J. Bourguignon" 
> > writes:
> >
> >> I've got a few "electric" key bindings like that,
> >> for example, when I type three dots in a sequence,
> >> I get ...
> >
> > And when you type two "l"s in a row, do you get
> > a special char inserted for that as well? I'm sure
> > there is a Unicode char with two parallel vertical
> > bars. Isn't that an even better idea than the three
> > dots one, because it appears much more frequently? No?
> > Why not?
> 
> It's not a question of typing fast, it's a question of typing easy.
> It's easier to type ... to get ... 
> than to type C-x 8 RET HORIZONTAL ELLIPSIS RET
> 

In http://blog.languager.org/2015/01/unicode-and-universe.html
I have written about 3 mutually exclusive and exhaustive prisons

 1. idiocy of ignorance
 2. slavery to savantery
 3. prison of penury


They correspond to:


1 Dummy
    To sell one's computer and work (and soul?) to a proprietary format and 
    word-processing software like Word
2 Wizard
    To master something arcnae such as latex (or mathml, lilypond, troff...)
3 Programmer
    Everything that is worth expressing can be expressed in ASCII.
    IOW...
    God made ASCII. All the rest is the work of man.

For a long time I used to be in category 3.
But of late I am rethinking¹ this position...
"Shakespeare is a better author than Gabriel García Márquez"²
seems a fine judgment to make.

"Shakespeare is a better author than Gabriel García Márquez because he used ASCII"
seems not so fine.

I know many people who would say Shakespeare was illiterate because he did 
not know how to use Word.
I think he is even more illiterate since he could never master the use of
a cell-phone.
----------------
¹ A rethinking for which emacs' neat input-methods is at least partly responsible
² I would have used Voltaire as example. Gabriel García Márquez makes my
point in the name itself!

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Drew Adams <drew.adams@oracle.com> writes:

>> Notice, that I asked the reader to compare the ease of input.
>
> Before I comment further, let me say that I agree with your point.
>
>> =>  super easy, two keys to type.
>> The unicode correspondance?  I would start typing C-x 8 RET double TAB
>> and not find it in the list.  So I would have to launch clisp,
>>    C-- slime RET clisp RET
>> wait for it to boot then type:
>>    (lschar :name "RIGHT_ARROW") RET
>> the search for double, and not find it, then copy and paste it from your
>> message, 
>>    (char-name #\⇒)
>> obtain the character name as "RIGHTWARDS_DOUBLE_ARROW", then type
>>    C-x 8 RET rightward double arrow RET
>> which, even if I had know it from the start, is still much more
>> difficult to type than just =>.
>
> Yes and no.  Yes, if you haven't used a particular Unicode char
> before or use it rarely.  No, if you use it often.
>
> If you use a particular Unicode character often, just give its
> insertion a command and bind that to a key.  If you have 30 such
> chars, put them all on a prefix key.  Or use completion on their
> command names (names you created, so easy for you to type, remember,
> complete to,...).
>
> IOW, it's not a big deal to insert Unicode characters, especially
> if you insert the same ones over and over.  You do not need to use
> `C-x 8 RET' each time.

While I agree that everything's better when everything's done in emacs,
I still use a few other programs than emacs, were I have text to edit. 

Therefore, I configured greek letters and a few mathematical symbols and
arrows, with a xmodmap that I use on my linux boxes.

Unfortunately, there is also a MacOSX box, and there the keyboard layout
is much less editable (once upon a time, there was a version of NeXTSTEP
or MacOSX that had editable keyboard layout, but I don't know if this is
still possible in Yosemite).

And I won't say about MS-Windows, happily I don't use it to edit text.


So while using emacs OR Linux everything can be bliss, there are still
often cases where you have to use not emacs and not Linux, or not your
own computer.


    +-------------------------------------------------------+
    |                                                       |
    |                                                       |
    |   Therefore it is easier to type lambda than λ.       |
    |                                                       |
    |                                                       |
    +-------------------------------------------------------+



-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Eli Zaretskii]

> From: "Pascal J. Bourguignon" <pjb@informatimago.com>
> Date: Wed, 25 Mar 2015 18:49:59 +0100
> 
> And I won't say about MS-Windows, happily I don't use it to edit text.

Say it.  Even Notepad has full support for Unicode.

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 11:40:17 PM UTC+5:30, Eli Zaretskii wrote:
> > From: "Pascal J. Bourguignon" 
> > Date: Wed, 25 Mar 2015 18:49:59 +0100
> > 
> > And I won't say about MS-Windows, happily I don't use it to edit text.
> 
> Say it.  Even Notepad has full support for Unicode.

ELISP> (setq ε 0.001)
0.001
ELISP> ε
0.001
ELISP> (defalias '≤ '<=)
≤
ELISP> (≤ 1 2)
t
ELISP> (≤ 1 0)
nil

Only small fly in ointment is that identifiers are not compared normalizing

ELISP> (setq flag t)
t
ELISP> flag
*** Eval error ***  Symbol's value as variable is void: flag

Re: if vs. when vs. and: style question

[Rusi]

On Thursday, March 26, 2015 at 2:57:42 AM UTC+5:30, Rusi wrote:
> On Wednesday, March 25, 2015 at 11:40:17 PM UTC+5:30, Eli Zaretskii wrote:
> > > From: "Pascal J. Bourguignon" 
> > > Date: Wed, 25 Mar 2015 18:49:59 +0100
> > > 
> > > And I won't say about MS-Windows, happily I don't use it to edit text.
> > 
> > Say it.  Even Notepad has full support for Unicode.
> 
> ELISP> (setq ε 0.001)
> 0.001
> ELISP> ε
> 0.001
> ELISP> (defalias '≤ '<=)
> ≤
> ELISP> (≤ 1 2)
> t
> ELISP> (≤ 1 0)
> nil
> 
> Only small fly in ointment is that identifiers are not compared normalizing
> 
> ELISP> (setq flag t)
> t
> ELISP> flag
> *** Eval error ***  Symbol's value as variable is void: flag


I wrote:
Hey! Emacs (Elisp) is civilized!
followed by definitions
of ≤ ε etc

First part got cut off for some reason...

Re: if vs. when vs. and: style question

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> I wrote: Hey! Emacs (Elisp) is civilized!
> followed by definitions of ...

Just because something is more specific, supposedly
advanced (in isolation), and possible to do (of course
it is), it doesn't mean it is a good idea.

Fore example: HTML mails instead of ASCII ditto, LaTeX
homepages (i.e., PDF files) vs. HTML, GUIs vs. CLI,
the mouse vs. the keyboard - all more recent,
supposedly more advanced methods, all possible, and
realized long ago.

Question: But then, why do so many people still don't
like them, and won't use them?

Answer: If you keep it simple, stick to the basics,
then the limit is on you - and, if you master the
basics (which you never do, completely, which is
natural, and a good thing), then the *sky* is the
limit. But: if you master the GUI, the GUI is
the limit!

This is why the people who use the basic, simple, but
combinable stuff are much better at computers, because
they don't put chains on themselves to crop their
creativity, activity, and energy. Even tho the basic
stuff is more difficult day one, very soon the
specific-stuff-people will hit the ceiling, a ceiling
which doesn't exist for the basic-stuff-people - their
ceiling is their own dedication and energy, and as
long as they have that, they are on an
upward trajectory.

Just look: You already discuss what chars are
included, what chars should be included, and so on.
So the limitation is what chars you can and can not
print?! That is bizarre! The ASCII people have
everything they need and the limitation is their own
mental-physical capacity, which they can constantly
push one centimeter upwards for every step they take.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Rusi]

On Tuesday, March 31, 2015 at 10:15:45 PM UTC+5:30, Emanuel Berg wrote:
> Rusi writes:
> 
> > I wrote: Hey! Emacs (Elisp) is civilized!
> > followed by definitions of ...
> 
> Just because something is more specific, supposedly
> advanced (in isolation), and possible to do (of course
> it is), it doesn't mean it is a good idea.
> 
> Fore example: HTML mails instead of ASCII ditto, LaTeX
> homepages (i.e., PDF files) vs. HTML, GUIs vs. CLI,
> the mouse vs. the keyboard - all more recent,
> supposedly more advanced methods, all possible, and
> realized long ago.
> 
> Question: But then, why do so many people still don't
> like them, and won't use them?
> 
> Answer: If you keep it simple, stick to the basics,
> then the limit is on you - and, if you master the
> basics (which you never do, completely, which is
> natural, and a good thing), then the *sky* is the
> limit. But: if you master the GUI, the GUI is
> the limit!
> 
> This is why the people who use the basic, simple, but
> combinable stuff are much better at computers, because
> they don't put chains on themselves to crop their
> creativity, activity, and energy. Even tho the basic
> stuff is more difficult day one, very soon the
> specific-stuff-people will hit the ceiling, a ceiling
> which doesn't exist for the basic-stuff-people - their
> ceiling is their own dedication and energy, and as
> long as they have that, they are on an
> upward trajectory.
> 

Ok So far...

After all unicode is TEXT (in 2015) as ASCII was in the last century.
And text is universal as unixers have known for half a century¹...

IOW Unicode is NOT
-- selling one's shirt (and soul) to a corp peddling a word-processing software
-- Nor is it about learning some arcane coding system
   where if one wants x₀ we have to write something ugly like $x_0$
   I want x₀ I have x₀ I want λ α Δ I have λ α Δ, as simple as that
   
The only cost is input methods.
For which as I already pointed out emacs tex-input method puts the cost of
the string "λ α Δ" at "\lambda \alpha \Delta"
IOW the lambda/alpha/Delta is what one would type anyway.
The extra backslash costs about as much as a shift costs to capitalize.

And tex input method is the more clumsy.
If you use greek a hell of a lot you can use greek keyboard.
After that δ Δ cost EXACTLY the same as the English d D
apart from the C-\ needed to switch

> Just look: You already discuss what chars are
> included, what chars should be included, and so on.
> So the limitation is what chars you can and can not
> print?! That is bizarre!

I have no idea what you are saying here…


--------------
¹ Well not strictly true; see http://blog.languager.org/2014/04/unicode-and-unix-assumption.html

Re: if vs. when vs. and: style question

[Emanuel Berg]

Yesterday night I read this which illustrates my point
- it was posted on
gwene.org.slashdot.rss.slashdot.slashdot.book.reviews
- indeed, quite a mouthful, but the post is
straightforward:

    As with any content management system, building
    a website using Drupal typically requires
    extensive use of its administrative interface, as
    one navigates through its menus, fills out its
    forms, and reads the admin pages and notifications
    — or barely skims them, as they have likely been
    seen by the site builder countless times before.
    With the aim of avoiding this tedium, speeding up
    the process, and making it more programmatic,
    members of the Drupal community created a "shell"
    program, Drush, which allows one to perform most
    of these tasks on the command line. At this time,
    there is only one current print book that covers
    this tool, Drush for Developers, Second Edition,
    which is ostensibly an update of its predecessor,
    Drush User's Guide. Read below for the rest of
    Michael's review.

Here we see a clear chronology:

First there is a shell...

Then there is an editor...

That's all you need to do advanced things...

Some people think the advanced things are too
advanced, so they come up with a CMS (e.g., Drupal)

Now people think the CMS isn't advanced enough, so
they have came up with a shell, namely Drush!

You see what just happened? "If anything can start
anew, then everything must continue". Is it amazing,
a waste of time, or a combination thereof? And: Will
the Usenet community supply the answer?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> You see what just happened? "If anything can start
> anew, then everything must continue". Is it amazing,
> a waste of time, or a combination thereof? And: Will
> the Usenet community supply the answer?

No.  Basically, the usenet community is lacking this tool:
http://tinyurl.com/nu4gm5g

In the old times, newbies would be seen developping such monstruosity by
other members of the computing center, and they'd be hit on the head and
harmony would be restaured.

Nowadays, the Internet learns about it too late, when they already have
pushed the code on github, written and published professional-looking
blog posts, and attracted a numerous following of 👍Likers.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Emanuel Berg]

It is not a big deal to insert Unicode chars compared
to doing things in general, like carving a mud cake
out the rear wheel of a bike. But compared to just
hitting the familiar keys on the keyboard to insert
the familiar ASCII, it is very slow. Which is even
more frustrating because doing so doesn't
add anything.

Again, it is just like the way natural writing
evolved. The first humans who wrote did a small
picture of a house, i.e. a house icon, to signify
a house. This practice was gradually abandoned because
it lacked flexibility, convenience, and speed.

Instead mankind went for the phonetic system were
letters indicate sounds, then you combine them
into words.

However, after spending a lifetime reading and
writing, to us it has come to full circle and the
phonetic letter/sound system of word formation has
come back to the iconic state. We don't *read*
"house", we see it. Compared to seeing a picture of
a house, it might be 50/50 which faster does
communicate the meaning. But let's say: "The big house
is green." How do you do that with images? Do you put
the image for "big" - ...how do you draw that? -
besides the house icon, and then add a green box?
Or do you draw one big, green house? How do you know
you are not supposed to look at the blue sky and white
clouds behind it?

It is exactly the same way with ASCII. We have had
hundreds and thousands of hours reading and writing
it. It doesn't matter some Unicode chars are clearer
if compared to the ASCII combination in isolation.
They are not clearer to the people who have never used
them, and aren't about to start, either.

Just as in the discussion (1+ data) vs. (+ 1 data) the
context - which here is: history, custom, and
experience - and not the properties of the things
compared, is the answer. With computers it is ASCII.
On university whiteboards anyone can draw whatever
chars anyone likes. I'm not saying, "Stop doing that,
use ASCII instead", am I? So the university people
should perhaps stick to their whiteboards as well!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

Emanuel Berg writes:
 >  (1+ data) vs. (+ 1 data)

I miss the original discussion, my apologies.

In C, increment and decrement operators are meant to use hw processor
instructions.

Is it the same for the LISP 1+ function?

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Mar 27, 2015 at 08:59:25AM +0100, Gian Uberto Lauri wrote:
> Emanuel Berg writes:
>  >  (1+ data) vs. (+ 1 data)
> 
> I miss the original discussion, my apologies.
> 
> In C, increment and decrement operators are meant to use hw processor
> instructions.
> 
> Is it the same for the LISP 1+ function?

That depends on the compiler. OTOH -- for a decent modern compiler, the
code generator would see the same, whether you type (+ 1 foo) or (1+ foo).

The optimizer is solving much harder problems than that. This holds true
for C as it holds for Lisp or Scheme or whatnot.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlUVD4sACgkQBcgs9XrR2kbphwCeMf4sCMOHCa+AJIVqDUB5cGVl
8vgAn1/D8DdYNHNtvPtUpKS7DrpLdnKD
=koIq
-----END PGP SIGNATURE-----

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

tomas@tuxteam.de writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Fri, Mar 27, 2015 at 08:59:25AM +0100, Gian Uberto Lauri wrote:
 > > Emanuel Berg writes:
 > >  >  (1+ data) vs. (+ 1 data)
 > > 
 > > I miss the original discussion, my apologies.
 > > 
 > > In C, increment and decrement operators are meant to use hw processor
 > > instructions.
 > > 
 > > Is it the same for the LISP 1+ function?
 > 
 > That depends on the compiler. OTOH -- for a decent modern compiler, the
 > code generator would see the same, whether you type (+ 1 foo) or (1+ foo).

Thank you very much.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Mar 27, 2015 at 09:11:24AM +0100, Gian Uberto Lauri wrote:
> tomas@tuxteam.de writes:

[...]

>  > That depends on the compiler. OTOH -- for a decent modern compiler, the
>  > code generator would see the same, whether you type (+ 1 foo) or (1+ foo).
> 
> Thank you very much.

To stay on topic (and to take the handwaving a bit out of the thread ;-), just
fire up a fairly recent Emacs, go to the *scratch* buffer (which should've come
up as default anyway), and type the following:

  (defun incr (x) (1+ x))

With the cursor at the end of the expression, type "C-x e" (that is eval-last-sexp).
You should see something in the echo area confirming that Emacs has grokked that.

Just below, type this:

  (disassemble 'incr)

closing off with "C-x e", as before. What do you see? Your function, expressed
as Emacs Lisp bytecodes (in a separate buffer). Something like:

  byte code for incr:
    args: (x)
  0       varref    x
  1       add1      
  2       return    

So hm. It seems: Elisp's byte code *has* a special instruction for "increment
by one", called, not surprisingly "add1".

Now repeat the experiment with the following, slightly modified lines:


  (defun inc1 (x) (+ 1 x))
  (disassemble 'inc1)

What's your result? What conclusions do you draw from that?

*My* point is: Emacs isn't just an editor (although it's very good at that).
It is an extremely discoverable programming environment. Just play with it.
It'll go out of its way to help you access its innards.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlUVIPMACgkQBcgs9XrR2kY0JACfZnn7SMUzFtjnBFHIXtDPXypr
7BQAn1g+gpQfVC323+/3sLFNdMufnvH5
=gLJC
-----END PGP SIGNATURE-----

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

tomas@tuxteam.de writes:
 > Just below, type this:
 > 
 >   (disassemble 'incr)
 > 
 > closing off with "C-x e", as before. What do you see? Your function, expressed
 > as Emacs Lisp bytecodes (in a separate buffer). Something like:

COOL!

 > *My* point is: Emacs isn't just an editor (although it's very good at that).
 > It is an extremely discoverable programming environment. Just play with it.
 > It'll go out of its way to help you access its innards.

Since it "exposes the inner workings" and thanks to Lisp, Emacs is much
more hackable and customizable to the user needs than modern behemoth
programming environments.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

<tomas@tuxteam.de> writes:

> On Fri, Mar 27, 2015 at 08:59:25AM +0100, Gian Uberto Lauri wrote:
>> Emanuel Berg writes:
>>  >  (1+ data) vs. (+ 1 data)
>> 
>> I miss the original discussion, my apologies.
>> 
>> In C, increment and decrement operators are meant to use hw processor
>> instructions.
>> 
>> Is it the same for the LISP 1+ function?
>
> That depends on the compiler. OTOH -- for a decent modern compiler, the
> code generator would see the same, whether you type (+ 1 foo) or (1+ foo).
>
> The optimizer is solving much harder problems than that. This holds true
> for C as it holds for Lisp or Scheme or whatnot.


Definitely.  
And this would be a good argument to remove/avoid 1+ and 1-.

(But remember, in my opinion, those are SUCC and PRED, and therefore
their presence represents a more fundamental idea; on the other hand a
lisp function named SUCC could like in pascal, obtain the successor
character too).

Again, one could argue indeed that it's a premature optimization: CL is
specified to be able to write very different implementation, very small
and simple implementations are possible, as well as very big and very
sophisticated ones.  Interpreters or compilers are possible.  (Already,
I feel there is more diversity in CL implementations than in C, even
taking into account Cint).


Some systems such as ACL2 are based on a subset of CL, using the list
notation even for arrays.   If we augment generality of principle, can
we remove specific and specialized operators.  In the end, we can reduce
all programming to lambda calculus.  There's a whole spectrum and the
question is where you put the cursor.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Mar 27, 2015 at 01:41:23PM +0100, Pascal J. Bourguignon wrote:
> <tomas@tuxteam.de> writes:
> 
> > On Fri, Mar 27, 2015 at 08:59:25AM +0100, Gian Uberto Lauri wrote:
> >> Emanuel Berg writes:
> >>  >  (1+ data) vs. (+ 1 data)

[...]

> > The optimizer is solving much harder problems than that. This holds true
> > for C as it holds for Lisp or Scheme or whatnot.
> 
> 
> Definitely.  
> And this would be a good argument to remove/avoid 1+ and 1-.

Oh, no! This exquisite redundancy in the language caters to my wetware
processor: it's a kind of side channel toward my colleague wetware
processors out there. The silicon processors just don't notice ;-)

What am I transmitting through this side channel? Call it "intention"
and wave with hands.

[...]

> Again, one could argue indeed that it's a premature optimizationc$ [...]

No, no, no! It's not about optimization (at least not mostly, at least
not these days). It's about those mysterious side channels.

Try to convince a musician to write always C-sharp instead of sometimes
D-flat, although they "are" the same note (since Bach, at least) (or are
they? On a violin? On a piano?).

rgds
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlUVVZgACgkQBcgs9XrR2kasDACeNNZZB5YXraNY4Wmug1ItUChB
znQAnjs/iMqmq3zNdyp/GNaLmoN5PAFB
=aOX6
-----END PGP SIGNATURE-----

Re: if vs. when vs. and: style question

[Rusi]

On Friday, March 27, 2015 at 6:35:42 PM UTC+5:30, tomas wrote:
> Try to convince a musician to write always C-sharp instead of sometimes
> D-flat, although they "are" the same note (since Bach, at least) (or are
> they? On a violin? On a piano?).

On the same page of Beethoven piano sonata 32 in C, you find a Ab and a G#.
According to the outlook above they are the 'same note' -- as I believed until
I got a piano with alternate tunings, ie in addition to the usual equal 
temperament there are now possible just-major and just-minor.

Put the piano into just-major and the G# sounds good and the Ab not.
Into just-minor and its the other way round.

Now if you look at this (humongous!) list of possible notes
http://www.kylegann.com/Octave.html
you can see that
G# ie augmented fifth is 772 cents ie 25/16
Ab ie minor sixth is 813 cents ie 8/5

IOW the augmented fifth and the minor sixth are separated by almost
HALF a SEMITONE. [The tempered G#=Ab is 800 a poor approximaion to both]

What's my point?

Civilization is digitization
Digitization is information-loss

This is true for music -- allowing for only 12 points in the ∞ spectrum between
frequency f and 2f makes music possible but also out of tune.

The same is true of language -- words are an indirection, pictograms are (more) direct.

And ASCII... Hoo Boy! That's one hell of information loss!
Thank God for unicode!
-------
PS. And I should write not G# and Ab but G♯ A♭

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Just as in the discussion (1+ data) vs. (+ 1 data) the
> context - which here is: history, custom, and
> experience - and not the properties of the things
> compared, is the answer. With computers it is ASCII.
> On university whiteboards anyone can draw whatever
> chars anyone likes. I'm not saying, "Stop doing that,
> use ASCII instead", am I? So the university people
> should perhaps stick to their whiteboards as well!

Absolutely!

This is to mean, there is still a lot of work to be done in computer
interfaces, notably for mathematical expression and manipulation, but
also for other data structures representation and manipulation by
non-programmers.



Also, one has to consider that even unicode is a premature space
optimization, being a fixed encoding of discretized forms, when the
domain obviously is evolving.  They're adding new versions of unicode
with new characters (now emojis!)   There are klingon unicode
characters, why not futurama I & II unicode characters?  There's a green
turtle, why not a blue beetle?  I'm not sure the unicode combinations
are complete either and that one could write any "ideogram" combining
existing characters.

After all, unicode is a CODE.


One could imagine in the future, computer systems that would perform the
encoding on a "document" basis, where transmission would involve
transmitting fonts and encoding along with the document structure.
(Notice that Postscript has this notion (and can have any other, since
it's Turing Complete), but I'm not sure it's retained in the more
restricted PDF).  The idea would be to have more meta-information
provided along with the document.  We could imagine that a letter to
your grandma could be stored along with a "dictionary map" of the
language you used, containing sufficient information so that an alien
(or a computer system 1000 years later) intercepting it would be able
to understand it easily.  We would need more sophisticated software, to
be able to deal intelligently with those documents. 


But this leads us very far from the alphabetic and ASCII idea.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> On a different note... For 50 years CS has been
> living in the impoverished world of ASCII.
> This makes people think CS and math are more far
> apart than they essentially/really are.

ASCII is sufficient for all computer use that is
indeed computer use.

Why do you think mankind abandoned the iconographic
baby-steps of the old Sumerians? Just so people 5000
years later can click on icons on their Macs and be
unable to spell their second names on a keyboard and
instead cutting and pasting it from their Phasebook
accounts? $^path/*$^@*(N:t)!!!

But: If you use the computer to write in Russian or
Greek for non-computer purposes, that's another thing
- use whatever you need.

Math and computers are not close. Yes, you can
describe computers in terms of math. But that's the
thing with math: it can model and express everything.

For example, during the industrialization of the USA
they were hysteric about stats of every little detail
in the entire process of doing every single little
thing that they were doing. This attitude is visible
even today in USA's sport world where some of the
hockey stars hold several hundred "records", some of
which are very creative and otherworldly. Does this
mean industrialization, or hockey for that matter,
"is" stats?

Just like math isn't computers.

Math is science, computers are engineering.

Math is the old Greeks, computers are the long-ears on
Easter Island.

Hands off computers!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Gian Uberto Lauri]

Emanuel Berg writes:
 > Rusi <rustompmody@gmail.com> writes:
 > 
 > > On a different note... For 50 years CS has been
 > > living in the impoverished world of ASCII.
 > > This makes people think CS and math are more far
 > > apart than they essentially/really are.
 > 
 > ASCII is sufficient for all computer use that is
 > indeed computer use.

If "computer use" means "computer programming", your sentence may be
true.

If "computer use" means "using a computer in everyday work", then
the sentence is "a bit" wrong.

 > Why do you think mankind abandoned the iconographic
 > baby-steps of the old Sumerians?

There is a remarkable number of people that still uses ideograms.

And the evolution of writing you refer to is bound more to
writing technology and speed of writing.

-- 
 /\           ___                                    Ubuntu: ancient
/___/\_|_|\_|__|___Gian Uberto Lauri_____               African word
  //--\| | \|  |   Integralista GNUslamico            meaning "I can
\/                 coltivatore diretto di software       not install
     già sistemista a tempo (altrui) perso...                Debian"

Warning: gnome-config-daemon considered more dangerous than GOTO

Re: if vs. when vs. and: style question

[Joost Kremers]

Gian Uberto Lauri wrote:
> Emanuel Berg writes:
> > Why do you think mankind abandoned the iconographic
> > baby-steps of the old Sumerians?
>
> There is a remarkable number of people that still uses ideograms.

Besides, even the old Sumerians didn't use just ideograms. The script
was to a large part syllabic, with characters representing syllables
(i.e., phonological values, though more than one per character).

-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

"Gian Uberto Lauri" <saint@eng.it> writes:

> Emanuel Berg writes:
>  > Rusi <rustompmody@gmail.com> writes:
>  > 
>  > > On a different note... For 50 years CS has been
>  > > living in the impoverished world of ASCII.
>  > > This makes people think CS and math are more far
>  > > apart than they essentially/really are.
>  > 
>  > ASCII is sufficient for all computer use that is
>  > indeed computer use.
>
> If "computer use" means "computer programming", your sentence may be
> true.
>
> If "computer use" means "using a computer in everyday work", then
> the sentence is "a bit" wrong.
>
>  > Why do you think mankind abandoned the iconographic
>  > baby-steps of the old Sumerians?
>
> There is a remarkable number of people that still uses ideograms.

And by the way, they do so more easily, not by typing on a keyboard, but
by drawing the ideogram on a tablet or smartphone screen with a stylus.
(The computer may then recognize the ideogram and normalize it).

The same could be done for mathematic ideograms.


> And the evolution of writing you refer to is bound more to
> writing technology and speed of writing.

Probably.  Western writing was based on hammer and scisor, or clay and
stylus, and later ink and quill, which leads more naturally to discrete
glyphs, while Eastern writing was based on ink and brush, and that led
more naturally to an ideographic script.  (The outcast being the
stranger hieroglyph).


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Rusi]

On Friday, March 27, 2015 at 6:15:15 AM UTC+5:30, Emanuel Berg wrote:
> Rusi  writes:
> 
> > On a different note... For 50 years CS has been
> > living in the impoverished world of ASCII.
> > This makes people think CS and math are more far
> > apart than they essentially/really are.

> Math and computers are not close. Yes, you can
> describe computers in terms of math. But that's the
> thing with math: it can model and express everything.

In the world I see around me, computers are used
- by shopkeepers for their accounts and inventories
- by engineers to design
- by artists to paint/compose etc
- by scientists to do science
- etc

In short computers seem to be able to model and control everything.
Does not seem so different from math does it?
And if you see the history of CS not different at all!

http://blog.languager.org/2015/03/cs-history-0.html

Re: if vs. when vs. and: style question

[Rusi]

On Wednesday, March 25, 2015 at 5:47:31 AM UTC+5:30, Emanuel Berg wrote:
> Rusi  writes:
> 
> > In general weaker is better
> > http://www.w3.org/2001/tag/doc/leastPower.html
> >
> > (when a b) ... (if a b) However (if a b c) ... (when ??)
> 
> What do you mean by "weaker"?

[At the risk of being over-simplistic...]
Weaker means less flexible

Maybe this link is more programmer-oriented than the earlier (web-oriented) one
http://blog.higher-order.com/blog/2014/12/21/maximally-powerful/

> 
> `if' can do three arguments, on the other hand it
> needs a `progn' to do several forms. `when' comes with
> implicit progn but cannot do the three way
> if-else if-else branch.
> 
> What I can see `if' is more flexible and you can
> change things without having to change the outermost
> `if', which is practical. Yes, with the use of `not'
> and `progn' if necessary, but I don't see a problem
> with that.
> 
> > Other example:
> >
> > destructuring-bind is strictly weaker than if/cond
> > and so better when usable
> 
> What is "destructuring-bind"?

I guess not a very good example.

Pattern-matching in modern FPLs would be more appropriate

foo [] = bla
foo (x:xs) = ble

Can always be translated into

foo l = if null l then bla else ble

The reverse is of course not always possible
But when pattern matching works its preferable to 'all-powerful' if-then-else

Notice also that pattern matching is a mix of 3 features that are usually separate -- 1. if 2. let 3. car/cdr ie selectors
Separately those 3 are strictly more powerful than pattern matching
And thats what makes pattern matching preferable (when it applies)

Re: if vs. when vs. and: style question

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Pattern-matching in modern FPLs would be more
> appropriate
>
> foo [] = bla foo (x:xs) = ble
>
> Can always be translated into
>
> foo l = if null l then bla else ble
>
> The reverse is of course not always possible But
> when pattern matching works its preferable to
> 'all-powerful' if-then-else
>
> Notice also that pattern matching is a mix of 3
> features that are usually separate -- 1. if 2.
> let 3. car/cdr ie selectors Separately those 3 are
> strictly more powerful than pattern matching And
> thats what makes pattern matching preferable (when
> it applies)

Aha - even more of the old functional programming
hysteria! Haskell, pattern matching... - are you sure
you are in the right newsgroup?

There is absolutely no rule that says "weak"
constructs are preferable, and especially not when
they are weak because they incorporate data that is
otherwise (in the "strong" version) readily available
to edit *as data* - i.e., exactly what it is.

Compare:

    (defun insert-hello ()
      (interactive)
      (insert-char ?h)
      (insert-char ?e)
      (insert-char ?l)
      (insert-char ?l)
      (insert-char ?o) )

    (insert-hello)

vs.

    (insert "hello")

Instead, the way to think is that the code should talk
both ways: it should tell the machine to do the
correct computation, all the while while showing and
indicating purpose to the person who writes and/or
reads the code!

For example, remember this example:

    (1+ data)

vs.

    (+ 1 data)

The "weak" vs. "strong" is the wrong way to think
about it.

In a discrete context, for example when iterating
a data structure or doing recursion, the `1+'
is preferable.

When just adding two data items, of which one happens
to be 1, the (+ 1 data) is better.

Perhaps that '1' will soon change. Big part of the
Lisp appeal is that it is so easy to change (tweak)
everything as you go along, in the light of experience
(which is often very recent), and then it goes on.

Or perhaps the '1' appears again in some other place
in the code, and when it does, the coder stops to
think, and it is concluded that it is the same data
item as the first one (ha) - i.e., both should be
replaced by an binding or variable...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Emanuel Berg]

I'd like to apologize for my arguing style in this
thread. Tho I'm not backing away from my views, I have
to reprimand myself for not presenting it in
a sarcasm-free way.

I say this because I know there are many young
programmers who eagerly read my posts, most likely
admiring me, trying to emulate me, and a must here
show them even the sun has spots, and even he who
hacks creation itself is fallible...

            *pause for astonished silence*

                        ... ;)

Now, from now on I'll just comment on things that
I *like*. It isn't as if there is any lack of them...

My final words on this is that style is not something
that should be over-analyzed. The definition of
a skilled programmer is his (or her, sometimes)
ability to write programs who carry out their intended
task that solves a real problem. Just as you cannot
tell a boxing world champ his style is bad because he
doesn't throw the jab, you don't have a case against
a programmer who can do what I just said.

On ASCII vs. Unicode, I think there is a very strong
case for ASCII but if anyone likes Unicode, by all
means use it all you like, I don't see any (big) harm
coming from that, just don't tell me it is better than
ASCII or "computers are math, only ASCII hides it so
no one noticed but us" (pseudo-quote) - this,
I consider dead wrong.

Hey... Why don't you Unicode and FP lovers do a new
editor called "Uhacs" (for Unicode, Haskell, and
Emacs) - the best thing with this editor is the
development time, which is actually zero. Because when
you start working on it, the result is a side-effect,
which is intolerable by definition, so you have to
stop :) Wait... oups, I did it again! But that joke
wasn't rude, was it? Rather, it is funny because it is
true :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

> Hey... Why don't you Unicode and FP lovers do a new
> editor called "Uhacs" (for Unicode, Haskell, and
> Emacs) - the best thing with this editor is the
> development time, which is actually zero. Because when
> you start working on it, the result is a side-effect,
> which is intolerable by definition, so you have to
> stop :) Wait... oups, I did it again! But that joke
> wasn't rude, was it? Rather, it is funny because it is
> true :)

Well, yes and no.

That is, you can make the joke about purely functional systems running
on Von Neuman archiectures, where anything is done only with side
effects.

But if you allow to consider the virtual machine provided by a purely
function system, and ignore the internal side effects required to
implement it, then you can indeed conceive a purely functionnal,
side-effect-free editor.

First of course, you have to start with a "side-effect-free" file
system.  So when you write a new file, you don't modify or erase the old
file, you actually store the new file in free space, and build a new
directory, almost similar to the old one, but with the new file in (and
perhaps an "old" file out), and up to the root directory.  You then have
a new editor monad using this new root directory.  

Therefore it's not funny because it's false, you can write an editor
without side effects at the level of your pure virtual machine and
system.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Rusi]

On Saturday, March 28, 2015 at 4:32:46 AM UTC+5:30, Pascal J. Bourguignon wrote:
> Emanuel Berg  writes:
> 
> > Hey... Why don't you Unicode and FP lovers do a new
> > editor called "Uhacs" (for Unicode, Haskell, and
> > Emacs) - the best thing with this editor is the
> > development time, which is actually zero. Because when
> > you start working on it, the result is a side-effect,
> > which is intolerable by definition, so you have to
> > stop :) Wait... oups, I did it again! But that joke
> > wasn't rude, was it? Rather, it is funny because it is
> > true :)
> 
> Well, yes and no.
> 
> That is, you can make the joke about purely functional systems running
> on Von Neuman archiectures, where anything is done only with side
> effects.

"Functional" has been a rather moving target in the last 50 years:

Recently came across this interview of John McCarthy
http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy

In the 1st question he says he learnt functional programming from Backus'
Fortran. Even to someone who is a bit of an old-timer like myself, this view 
is amazing.  Younger kids dont even get how shocking is being said here:
When I mentioned this on the Haskell list someone (only) connected it with
Backus' Turing award lecture.

Whereas if one reads the Turing award lecture, clearly Backus is doing penitence
for the 'sin' of inventing Fortran, 20 years after the invention.

And yet one needs to admit that in 1957 Fortran was a functional language --
the very name carries that intention.
By 1977 that stand needed a very public withdrawal.

And so in summary:
In 1957 For(mula Tran(slator) was the (one and only) functional language
1960 Lisp
60s Lisp+APL
70s ML, Also 'theoretical languages' like ISWIM
80s Lazy languages FPLs like SASL, KRC, Miranda start appearing
While the landmark SICP is from 80s, we also have the beginning rumbles saying
Lisp has retarded the progress of functional programming and CS education
by 10 years [David Turner, Phil Wadler]
[Interestingly it appears that in the late 80s McCarthy said Lisp was not
functional]
90s Haskell
This century: Some unexpected resurgence of Lisp as functional -- CLojure

I am ready to bet that 20 years from now Haskell wont be regarded as a
properly functional language.

Beginning rumbles: Bob Harper's Haskell is exceptionally unsafe

[Seems to be removed, heres an archive version
https://web.archive.org/web/20150102135555/https://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-unsafe/
]

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Rusi <rustompmody@gmail.com> writes:

> On Saturday, March 28, 2015 at 4:32:46 AM UTC+5:30, Pascal J. Bourguignon wrote:
>> Emanuel Berg  writes:
>> 
>> > Hey... Why don't you Unicode and FP lovers do a new
>> > editor called "Uhacs" (for Unicode, Haskell, and
>> > Emacs) - the best thing with this editor is the
>> > development time, which is actually zero. Because when
>> > you start working on it, the result is a side-effect,
>> > which is intolerable by definition, so you have to
>> > stop :) Wait... oups, I did it again! But that joke
>> > wasn't rude, was it? Rather, it is funny because it is
>> > true :)
>> 
>> Well, yes and no.
>> 
>> That is, you can make the joke about purely functional systems running
>> on Von Neuman archiectures, where anything is done only with side
>> effects.
>
> "Functional" has been a rather moving target in the last 50 years:
>
> Recently came across this interview of John McCarthy
> http://www.infoq.com/interviews/Steele-Interviews-John-McCarthy
>
> In the 1st question he says he learnt functional programming from Backus'
> Fortran. Even to someone who is a bit of an old-timer like myself, this view 
> is amazing.  Younger kids dont even get how shocking is being said here:
> When I mentioned this on the Haskell list someone (only) connected it with
> Backus' Turing award lecture.
>
> Whereas if one reads the Turing award lecture, clearly Backus is doing penitence
> for the 'sin' of inventing Fortran, 20 years after the invention.
>
> And yet one needs to admit that in 1957 Fortran was a functional language --
> the very name carries that intention.
> By 1977 that stand needed a very public withdrawal.
>
> And so in summary:
> In 1957 For(mula Tran(slator) was the (one and only) functional language
> 1960 Lisp
> 60s Lisp+APL
> 70s ML, Also 'theoretical languages' like ISWIM
> 80s Lazy languages FPLs like SASL, KRC, Miranda start appearing
> While the landmark SICP is from 80s, we also have the beginning rumbles saying
> Lisp has retarded the progress of functional programming and CS education
> by 10 years [David Turner, Phil Wadler]
> [Interestingly it appears that in the late 80s McCarthy said Lisp was not
> functional]
> 90s Haskell
> This century: Some unexpected resurgence of Lisp as functional -- CLojure
>
> I am ready to bet that 20 years from now Haskell wont be regarded as a
> properly functional language.
>
> Beginning rumbles: Bob Harper's Haskell is exceptionally unsafe
>
> [Seems to be removed, heres an archive version
> https://web.archive.org/web/20150102135555/https://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-unsafe/
> ]

Ah good.  So I guess I can avoid learning Haskell, I'll wait for the
next stable functional language.  In the meantime lisp goes strong as it
has for more than 56 years.  I'll stay with lisp.

:-)

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:


>> (defun find-thingy (name)
>>   (or (find-thingy-in-whatcha name)
>>       (find-thingy-in-macall name)
>>       (find-thingy-in-it name)
>>       (error "not found")))
>>
>> which is much more concise and clear than ...
>
> But is it clearer than
>
>     (defun look-here () "here")
>
>     (cond
>      ((look-here))
>      ((look-there))
>      (t (message "Not found")))
>
> as well? I always thought of `cond' and `if' as
> identical save for syntax.

In my opinion, yes.  

I believe this cond form is harder to read, 
because it is inhabitual.

Personnally, I would understand it as well, 
but I'm not sure it would be the case of all lispers.


-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk

Re: if vs. when vs. and: style question

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> I believe this cond form is harder to read, because
> it is inhabitual.

That's interesting, I think cond is much more
understandable, not because of the cond itself but
because the `or' is often used in logic to do
branching and so on. In your example, it is used as
a search which is much more uncommon. But for you, it
instantly looks like search, I'm sure.

My attitude is use whatever you feel like... man >"?

-- 
underground experts united

Re: if vs. when vs. and: style question

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 1271 bytes --]

() Marcin Borkowski <mbork@wmi.amu.edu.pl>
() Mon, 23 Mar 2015 23:53:02 +0100

   Notice: by “better” I mean “more idiomatic”, or
   “easier/faster to read for a human”, or “more likely
   to be used by an experienced Elisp hacker”, etc.

Personally, i loathe 1-armed-‘if’ expressions; they are a blight
on the smoothness, equivalent to "umm", "err" in a formal talk.
When i inherit code (e.g., EDB), i early-on put effort into
killing those abominations.  (This has the predictable side
effect of introducing bugs, but is anyway useful for
familiarizing myself w/ the code, which in the long run is
better -- especially if those bugs can be recognized and fixed!)

For ‘or’ and ‘and’, i use those very much in Scheme and very
little in Emacs Lisp, and preferentially for pure expressions.
I like (and use) ‘when’ and ‘unless’ for their implicit ‘progn’.

(Insert quote on aesthetics vs principles, here.  :-D)

-- 
Thien-Thi Nguyen -----------------------------------------------
  (if you're human and you know it) read my lisp:
    (defun responsep (type via)
      (case type
        (technical (eq 'mailing-list via))
        ...))
---------------------------------------------- GPG key: 4C807502

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: if vs. when vs. and: style question

[Emanuel Berg]

Thien-Thi Nguyen <ttn@gnu.org> writes:

> Personally, i loathe 1-armed-‘if’ expressions; they
> are a blight on the smoothness, equivalent to "umm",
> "err" in a formal talk.

Ha! Yes, they look so lost and sidetracked and out of
focus. But that shouldn't stop anyone from using them.
Just like the "umm"s and "err"s in talk, which convey
information or give the talker time to formulate the
next sentence without being interrupted, the 1-armed
bandits serve a purpose.

Also, sometimes nil is what you want:

    (if nil 1)
    (if nil 1 nil)

> When i inherit code (e.g., EDB), i early-on put
> effort into killing those abominations. (This has
> the predictable side effect of introducing bugs, but
> is anyway useful for familiarizing myself w/ the
> code

Ha again! I just wrote I wouldn't do it, but this is
a great point. "May I indent your code?" is perhaps an
insult but it can be rephrased as "May I muck around
with your code until I understand it?" - at what time,
it will be re-indented as the inheritor likes it as
a positive side-effect. Learning by doing is doing by
learning! If anything can start anew, then everything
must continue!

-- 
underground experts united

Re: if vs. when vs. and: style question

[Emanuel Berg]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> assuming (e1) and (e2) are some expressions, all
> three forms:
>
> (if (e1) (e2))
>
> (when (e1) (e2))
>
> (and (e1) (e2))
>
> are semantically equivalent. Which one is better
> style (and when)? I would guess that =when= is
> better iff (e2) is a =progn= (since we can drop the
> =progn= altogether, and this seems to be the point
> of =when=), and =and= might be considered better
> (well, maybe) by some people when both (e1) and (e2)
> are very short (though I personally would avoid
> that, since =if= seems easier for a human to
> understand at a first glance). Am I right?

I don't think `and' should be used to evaluate and
return =stuff= (I mean evaluate as in side-effects),
rather, use it as the familiar gate of binary logic,
thought here it isn't binary but can be of whatever
arity. But no rule without exceptions, of course...

To me `if' + `progn' is better than `when' because
I am more familiar with those constructs and also, if
I ever have to change something, which happens all the
time, I will not have to bother thinking "is this
still a `progn'? if it isn't, should I remove the
`when'? if I don't, will anyone wonder why I used
a `when' instead of `if'? Less thinking, more coding
I'd say with plain `if' and then whatever is needed
from there to get it done.

But I can't say I'd hit the ceiling if anyone used
`when', with or without the need for a `progn' in the
equivalent `if' clause. Using `and' for no reason I'd
consider worse because that could be really confusing.

-- 
underground experts united