[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon May 15 17:13:47 2001 
Subject:Re: filenames, argument list separators + gsl extension 
From:Aaron Sloman See text for reply address 
Volume-ID:1010515.05 

[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

kers@hplb.hpl.hp.com () writes:

> Date: 15 May 2001 12:51:10 GMT
> Organization: Hewlett-Packard Laboratories, Bristol, UK
>
> In article <3b01019e.257882975@news.cis.dfn.de>,
> 	Jonathan.Cunningham@tesco.net (Jonathan L Cunningham) writes:
> > On Mon, 14 May 2001 22:50:29 GMT, hedgehog@electric-hedgehog.net
> ....
> > This is where lambda expressions, or pop procedures, are more
> > powerful but syntactically clumsier. This will freeze in
> > the second argument of a three argument function:
> >
> > define midclosure(f, arg);
> >     procedure x, y;
> >         f(x, arg, y);
> >     endprocedure
> > enddefine;
>
> 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 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.)

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. 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.

But your example of an expression producing a closure of an
infix operator

    ?1 - 3

would then have to be written

    nonop -(% ?1, 3 %)

> 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>(% ... %)

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) =>

Cheers.

Aaron "I should be doing something else" Sloman
===
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk   (ReadATas@please !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html