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
|