sml operators and/or

[guthrie]

I was trying to use sml's logical functions andalso & orelse as
partially applied arguments to a reduce (fold), but couldn't get them
to work with either "op", secl/secr, or just partially applying them.

They seem to have a special syntactic status; Paulson describes
andalso as an "abbreviation".

Can they be used as HOFs?

[Thant Tessman]

The magical thing about andalso and orelse is that they don't evaluate
their second 'argument' when they don't need to. If the first 'argument'
to andalso is false, it doesn't evaluate its second argument. If the
first 'argument' to orelse is true, it doesn't evaluate its second argument.

In this sense, they are not normal functions, and do indeed have special
syntactic status.

-thant

[Matthias Blume]

Thant Tessman <thant....@gmail.com> writes:

Actually, they are not just not normal functions, they aren't functions
at all! They are just syntax. If you want to partially apply them, you
need to define your own, which is done quite straightforwardly:

fun myAnd x y = x andalso y
fun myOr x y = x orelse y

Matthias

[guthrie]

On Jan 12, 1:54 pm, Matthias Blume <bl...@hana.uchicago.edu> wrote:
> Actually, they are not just not normal functions, they aren't functions
> at all!  They are just syntax.  If you want to partially apply them, you
> need to define your own, which is done quite straightforwardly:
>
> fun myAnd x y = x andalso y
> fun myOr x y = x orelse y
>
> Matthias

Thanks,
That's what I had concluded, and done.

I presume that this is clearly documented somewhere, but I didn't find
it...

[Matthias Blume]

guthrie <gut...@mum.edu> writes:

> I presume that this is clearly documented somewhere, but I didn't find
> it...

The full grammar for Standard ML is given in the Definition of Standard ML (Revised) in Appendix B. The expression forms involving "andalso" and "orelse" appear on page 63 in my copy of the book.

The semantics of these forms is explained as "derived" in Figure 15 or page 56.

(The forms boil down to "if" expressions -- which themselves boil down further to "case" expressions -- which, in turn, boil down to explicit applications of a literal function expression which has the form "fn <match>".)

Matthias

[guthrie]

On Jan 13, 10:53 am, Matthias Blume <bl...@hana.uchicago.edu> wrote:

Thanks.

I don't happen to have a copy handy(!) - I would have hoped that there
would /should be more accessible (public) language definitions! E.G.
online, like JLS, ... :-)

In any case, this means that there is no convenient builtin operator
for logical reduce usage?

[Thant Tessman]

They're built in, but the spelling of their names is a little tricky:

(fn(x,y)=>x andalso y)
(fn(x,y)=>x orelse y)

So for example:

List.foldl (fn(x,y)=>x orelse y) false [false, false, true, false];

As for the grammar of Standard ML, googling about reveals a few things
online, but I found the chart in the back of "ML for the Working
Programmer" to be particularly insightful.

-thant

[Torben Ægidius Mogensen]

guthrie <gut...@mum.edu> writes:

> On Jan 13, 10:53 am, Matthias Blume <bl...@hana.uchicago.edu> wrote:
>> guthrie <guth...@mum.edu> writes:
>> > I presume that this is clearly documented somewhere, but I didn't find
>> > it...
>>
>> The full grammar for Standard ML is given in the Definition of Standard ML (Revised) in Appendix B.  The expression forms involving "andalso" and "orelse" appear on page 63 in my copy of the book.
>>
>> The semantics of these forms is explained as "derived" in Figure 15 or page 56.

> I don't happen to have a copy handy(!) - I would have hoped that there

> would /should be more accessible (public) language definitions! E.G.
> online, like JLS, ... :-)
>
> In any case, this means that there is no convenient builtin operator
> for logical reduce usage?

The reason andalso and orelse are not functions is that they do not
evaluate both their arguments -- (p andalso q) will first evaluate p
and if it is false not even bother to evaluate q. But functions in
SML always evaluate all their arguments in advance, so Thant's
suggestion of using (fn (p,q)=>p andalso q) changes that: This
function will evaluate both arguments in advance. This may or may not
be a problem, depending on the context.

Haskell and other lazy languages do not evaluate function arguments
before application, so you can define

p `andalso` q = if p then q else p

and get a behaviour like SML's andalso.

Torben