[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 16 05:42:49 2001 
Subject:Re: filenames, argument list separators + gsl extension 
From:Chris Dollin 
Volume-ID:1010516.01 

In article <9dro4b$185v$1@soapbox.cs.bham.ac.uk>,
	Aaron.Sloman.XX@cs.bham.ac.uk (Aaron Sloman See text for reply address) writes:
> [To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
> 
> kers@hplb.hpl.hp.com () writes:
> 
>> Just to show where we're going, the proposed Spice syntax for writing
>> the midclosure of f is
>>
>>     f( ?1, arg, ?2 )
> 
> I would recommend richer syntax. Otherwise you could have a very
> complex expression which LOOKS like a function call, but turns out
> not to be because buried in it is a "?" followed by a numeral.

It would have to be a ?N which stood alone as an argument, of course.
 
> It is a very elegant idea, but like many elegant idea does not have
> enough syntactic redundancy for real software engineering: Programs
> written in such a language would be hard to maintain. (I think ML
> is another example; having seen people struggling to parse complex
> expressions using the very elegant ML syntax.)

The intention is that the hole syntax be used for *small* expressions;
it's to make small things *stay* small. (One of the irritations for me
of Pop is that writing tiny functions like

    procedure (x); x + 1 endprocedure

takes up so much room: it's hard to see the effect of the function
because the surrounding syntax is so big).

> One solution would be to require the relevant set of parentheses
> to be decorated to show that that's not a normal procedure call but
> a closure constructor.

This is not a general solution, because the hole syntax is applicable to
things that do not have a "relevant set of parentheses", such as

    x @consPair _

which is one way of writing the equivalent of

    procedure (y); conspair( x, y ) endprocedure

> Eg. something like, dare I suggest it:
> 
>>     f(% ?1, arg, ?2 %)
> 
> That would then nicely generalise to allow all these:
> 
>>     f(% ?1, arg1, arg2 %)
> 
>>     f(% arg1 arg2, ?2 %)
> 
>>     f(% arg1 arg2, arg3 %)
> 
> whereas your syntax, if I have understood it, handles only the first
> two cases.

That's true ("only" of this example, natch). I wonder if that's worth
doing something about.

> But your example of an expression producing a closure of an
> infix operator
> 
>     ?1 - 3
> 
> would then have to be written
> 
>     nonop -(% ?1, 3 %)

At this point using one of the lambda-syntaxes of Spice would be
nicer:

    (x => x - 3)
    fun x => x - 3 endfun

the first being for the Truly Terse and the second for those who like
a little forshadowing in their programmatic narrative.
 
>> where ?1 and ?2 are "holes", implicit arguments for the "nearest
>> surrounding holey context", which is the function-application (not
>> the commas: although that would make semantic sense, it would generally
>> be not useful).
> 
> Then ?1, ?2, ... would be holes that are implicit arguments for the
> nearest surrounding expression of the form
> 
>    <exp>(% ... %)

Hmm. I don't like the reliance on the %-brackets, but it may be we're
allowing a little to much in the way of terseness. Note, however, that
Spice has a richer compile-time type-system than Pop; it's likely that
mistaking a closure of f for a call of f will induce a type failure
on at least one of compile-time and run-time. [I hope!]
 
> Novices may learn through falling over obscure bugs that they have
> to interpret the "nearest surrounding expression" has to be
> interpreted with care.
> 
> Compare: which of these will mishap?
> 
>     last([^tl ^hd])(hd([[^tl]]))([3 4]) =>
> 
>     last([^tl ^sqrt])(hd([^hd]))([3 4]) =>
> 
>     last([^tl ^hd])(hd([[^sqrt]]))(3) =>

I don't see the parallel.

("nearest surrounding expression" is what I informally wrote for the
posting: I'd tighten it up for tutorial purposes.)
 
> Aaron "I should be doing something else" Sloman

Think of it as a public duty, given what Steve and I would like to do
with such a language.
 
-- 
Hopeful Hedgehog