filenames, argument list separators + gsl extension 
Author Message
 filenames, argument list separators + gsl extension

Quote:
> Space being a valid char in an identifier, seems absurd.

> Why?

> Spaces occur in identifiers all over the place. Here are some examples.

>     Christopher James Dollin
>     Windows 95
>     Red Hat Linux
>     The Sorceress and the Cygnet
>     Thief of Time
>     A Song for all Seasons
>     Shifting Sands
>     For Girls Who Grow Plump In The Night
>     Spice manual
>     Chatty guide
>     Hewlett-Packard Laboratories


<side track>: Is this part of the "get computers to understand people" idea ?
The "more natural/human" is the WRONG goal; motivated by US-Disney
and "the little man in the box syndrome".   "He almost understands me".
Increased knowledge, reduces the apparent chaos/complexity of the
universe into fewer rules/principles.  Progress = simplification.

Pop-11 has taken the wrong route (too late now) in having multiple
syntaxes to say:
    IF GreenBall NOT broken THEN ....
The limitation on computing is the complexity, which overwhelms humans.
Greater freedom (more "natural") equals greater complexity.
Lets not be driven/misled by MS-marketing   <end side track>

Quote:
> > My prefered OS (oberon) allows only alpha-numeric and 'period' for fileIDs

> Oh, spit. That's ridiculous. No hyphens, underbars, plus signs, etc? I
> think that's taking things to extremes I only dream (badly) of. I presume
> you're allowed arbitrarily long filenames?

MaxChar=31; I'm constrained by physical realities. eg. CharLenPerScreenLine

Quote:
> > but files of other systems, with 'invalid' chars can be read,
> >    by quoting. eg:  "c:/o236/file-name.htm"

> So the file-system hadler accepts names with arbitrary characters, you
> just can't create files with them in? How ... strange.

 I don't know the implementation details, but the native file system is
optimised (life is about trade-offs) and to read/write DOS, Linux-based
files the non-standard "patch" is used.

Quote:
> > Is this matter related to pop11's failure to detect the missing separator
> > in the local var. declaration, below ?  My understanding is that comma
> > (only) is a a valid separator here ?

> >     define listify(list) -> result;
> >               vars next   tail;

> HELP VARS says:

>     For the present, commas may be omitted except after an initialisation,
>     but it is recommended that they be used.

Thanks. That reduces a very uncomfortable feeling.
But I find such ambiguity unacceptable in computing.

Quote:
> and I'd assume it's mostly a backward-compatability relic from the days
> of POP2.

These apparently trivial details cause 'failure'.

Quote:
> No, there's no relationship between the one and the other.

> (c) My own feeling is that although the recent discussions of syntax for
> various types of data-constructing expressions are interesting and
> could, if they had occurred around 1970, have led to much better syntax
> for the pop family, they are far less important for real users than
> other "semantic" issues like the availability of powerful libraries that
> extend what you can easily do, the availability of new debugging and
> development tools, etc.

Yes, consider the cost/benefit.  The discussed changes seem to me
(a beginner) to be drastic, hence potentially disasterous.
Inevitably the greatest added value per effort (especially for beginnners
usage) is acheived by mundane tasks - which no one want's to discuss.
eg. "set up a system" (NOT do the job) whereby new users report typos
in the tutorials, which are fixed.
 ...

Quote:
> By comparison with "semantic" extensions of the above types, I believe
> changes to the syntax of existing constructs are really of marginal
> importance!

Very important, marginal value, hence not recommended to change.
...

Quote:
> Is anyone interested in forming a collaborative project to provide
> the gsl extension to pop-11???

Are the extensions just mathematical facilities ?
Can you list some example(s) ?

Chris Glur.



Sat, 01 Nov 2003 06:04:16 GMT  
 filenames, argument list separators + gsl extension


Quote:
>> Space being a valid char in an identifier, seems absurd.


>> Why?

>> Spaces occur in identifiers all over the place. Here are some examples.

>>     Christopher James Dollin
>>     Windows 95
>>     Red Hat Linux
>>     The Sorceress and the Cygnet
>>     Thief of Time
>>     A Song for all Seasons
>>     Shifting Sands
>>     For Girls Who Grow Plump In The Night
>>     Spice manual
>>     Chatty guide
>>     Hewlett-Packard Laboratories

> <side track>: Is this part of the "get computers to understand people" idea ?

No.

It's an observation that "real" names can have more-or-less arbitrary
characters in them, especially spaces.

Quote:
> The "more natural/human" is the WRONG goal; motivated by US-Disney
> and "the little man in the box syndrome".  

Wrong for what? Wrong why?

Quote:
> "He almost understands me".
> Increased knowledge, reduces the apparent chaos/complexity of the
> universe into fewer rules/principles.  Progress = simplification.

If I were sloganising, "Progress = abstraction" would be more to my
taste. The real world is not simple, even if its underlying rules are
(and that's one of life's unknowns).

Quote:
> Pop-11 has taken the wrong route (too late now) in having multiple
> syntaxes to say:
>     IF GreenBall NOT broken THEN ....

Why do you think Pop's taken a wrong route here? Do you mean to
suggest, for example, that it errs in having both `if` and `unless`
statements? Do you have empirical evidence to support this? I'm afraid
I can only offer personal, anecdotal evidence, which is that single-arm
conditionals with negative predicates are easier to understand using
`unless positive-condition` than 'if negative-condition'.

(Incidentally note the use of identifiers containing - signs.)

Quote:
> The limitation on computing is the complexity, which overwhelms humans.

It's the *detail* that kills.

Quote:
> Greater freedom (more "natural") equals greater complexity.

People master enormous amounts of complexity without apparent effort.
English is more complex in structure, and more flexible in semantics,
than any programming language I know of. Of course it's not as *exact*
without becoming very verbose.

Quote:
> Lets not be driven/misled by MS-marketing   <end side track>
>> > My prefered OS (oberon) allows only alpha-numeric and 'period' for fileIDs

>> Oh, spit. That's ridiculous. No hyphens, underbars, plus signs, etc? I
>> think that's taking things to extremes I only dream (badly) of. I presume
>> you're allowed arbitrarily long filenames?
> MaxChar=31; I'm constrained by physical realities. eg. CharLenPerScreenLine

That's not a "physical reality", that's an arbitrary system restriction.
There's no good reason for a name to be restricted to the length of a
screen line (which in any case is ...  estimates ... about 160 characters,
using my current font & the fat compile-my-project window).

Quote:
>> > but files of other systems, with 'invalid' chars can be read,
>> >    by quoting. eg:  "c:/o236/file-name.htm"

>> So the file-system hadler accepts names with arbitrary characters, you
>> just can't create files with them in? How ... strange.
>  I don't know the implementation details, but the native file system is
> optimised (life is about trade-offs) and to read/write DOS, Linux-based
> files the non-standard "patch" is used.

Well, it may be an "optimisation", but it optimises the wrong thing. It
turns out to be nice for people to give files long meaningful names. It's
also nice for *programs* to be able to create files with long names
(such as 'map: int x int -> int') rather than having to implement
(all over again) a mapping from nice long descriptions to short file names.

Quote:
>> > Is this matter related to pop11's failure to detect the missing separator
>> > in the local var. declaration, below ?  My understanding is that comma
>> > (only) is a a valid separator here ?

>> >     define listify(list) -> result;
>> >               vars next   tail;

>> HELP VARS says:

>>     For the present, commas may be omitted except after an initialisation,
>>     but it is recommended that they be used.
> Thanks. That reduces a very uncomfortable feeling.
> But I find such ambiguity unacceptable in computing.

Why?

I'd prefer that the comma be mandatory, myself, but for robustness, not
because of some prejudice about ambiguity. (It's also not ambiguous;
there's a single meaning, with a *choice* of syntax.)

Quote:
>> and I'd assume it's mostly a backward-compatability relic from the days
>> of POP2.
> These apparently trivial details cause 'failure'.

Of what?

Actually, I agree that apparently trivial details can turn out to be
important in language syntax. The one above is not, I think, one of
those cases.

Quote:
>> No, there's no relationship between the one and the other.


>> (c) My own feeling is that although the recent discussions of syntax for
>> various types of data-constructing expressions are interesting and
>> could, if they had occurred around 1970, have led to much better syntax
>> for the pop family, they are far less important for real users than
>> other "semantic" issues like the availability of powerful libraries that
>> extend what you can easily do, the availability of new debugging and
>> development tools, etc.

> Yes, consider the cost/benefit.  The discussed changes seem to me
> (a beginner) to be drastic, hence potentially disasterous.

I am not myself proposing significant changes to Pop's syntax, although
I *do* think we should seriously reconsider our quoting conventions.
The syntax I have mentioned is that of existing experiments grounded in
my experiences using Pop11.

As Jonathan alluded to, the reality is that if a language does not
change, it dies. Some changes have to be drastic to make progress.

Quote:
>> By comparison with "semantic" extensions of the above types, I believe
>> changes to the syntax of existing constructs are really of marginal
>> importance!

> Very important, marginal value, hence not recommended to change.
> ...

For existing Pop11 code, that's very likely the best route. But if Pop
is to continue to evolve, then we should consider *how* it should evolve
for best effect.

Part of that is syntax; part of it is the Poplog VM. The latter controls
what kind of things can be said; the former controls how *easily* they
may be said. For example, Pop's syntax for closures is pretty easy to
write and read; it gets used a *lot*. It's not perfect (I think Spice
"holes" will turn out better, but they've not been used in anger), but
it's easier than explicit lambda-expressions. If it's clumsy to write,
*it doesn't get used*.

--
Hedgehog



Sat, 01 Nov 2003 06:50:29 GMT  
 filenames, argument list separators + gsl extension

Quote:

>Part of that is syntax; part of it is the Poplog VM. The latter controls
>what kind of things can be said; the former controls how *easily* they
>may be said. For example, Pop's syntax for closures is pretty easy to
>write and read; it gets used a *lot*. It's not perfect (I think Spice
>"holes" will turn out better, but they've not been used in anger), but
>it's easier than explicit lambda-expressions. If it's clumsy to write,
>*it doesn't get used*.

Pop's closures (partial application) are very useful, and much more
convenient than lambda-expressions as in Lisp.

There was a discussion on this group a few years back (probably even
before LIB objectclass) about the advantages of object-oriented
programming. Somehow the question got raised about how you would
get the same effect as pop closures in an OO language.

It can be done, without using anything like closures or
lambda expressions. And it's messy: you need to define a new class.

As an interesting corollary, one of the few "big" changes to the
syntax of Java, after its first release, was the provision of a
mechanism for defining anonymous classes. (In the same way that
the pop11 "procedure" syntax lets you define anonymous procedures.)
IMO, one main purpose of anonymous classes was precisely those
cases where, in pop, we would use closures.

Most of the Java effort has gone into providing
libraries of higher level constructs, such as java beans, with
very few changes to the syntax of the language. This is, of
course, in line with Aaron's comments, and what we would expect
in pop. But should we, for example, want to add the concept
of anonymous classes to lib objectclass? Pop11 is so rich,
syntactically, that I don't suppose anyone has felt any need
for them, but going one step further than Chris's remark above:
if it ain't in the language *it sure as hell doesn't get used*.

OK, I shouldn't be spending time on this, but to provide a
few examples, suppose we have a function called "triple" as follows:

define triple(x, y, z);
  [first ^x second ^y third ^z]=>
enddefine;

It is fairly obvious what this does:

triple("one", "two", "three");
** [first one second two third three]

And closures can freeze in the last argument(s), as in

triple(% "jump" %) -> double;

so that

double("hop", "skip");
** [first hop second skip third jump]

Suppose we now want to freeze in the middle argument instead?

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;

(It's actually a bit more general than that, but let's not
get too pedantic here.)

We can use it as follows:

midclosure(triple, "beta") -> doublet;

doublet("alpha", "gamma");
** [first alpha second beta third gamma]

doublet("bet", "best");
** [first bet second beta third best]

Ok, how would you do this in a language which doesn't have
procedures as objects which can be manipulated in this way?
In an object oriented language, you can pass around objects
instead.

Using objectclass (which I'm not very familiar with, so
maybe this can be cleaned up), you will need an object
which will represent the three arg function "triple".
(Remember, from now on, we are pretending that we can't
pass around functions are arguments to other functions.)

First we declare the class of the object for the triple
function:

define :class three_arg_func;
enddefine;

There is nothing in it, because we don't really need a
whole new class. It is only there so that we can create
an object. The only thing about this object is that it
represents a three argument function, so let's declare
that next:

define :method apply_three_arg(f:three_arg_func, x, y, z);
   [first ^x second ^y third ^z]=>
enddefine;

This is our old friend "triple" -- or rather, it is the
declaration of what triple will do. We still have to
create the actual object:

consthree_arg_func() -> triple;

Now we can use the object like a function:

apply_three_arg(triple, "alpha", "beta", "gamma");
** [first alpha second beta third gamma]

Now we are in a position to create the equivalent of
a closure, or lambda expression. We will need to
inherit the apply_three_arg function, so we will
need a new class:

define :class midclosure is three_arg_func;
    slot middlearg;
enddefine;

This new class will represent a two argument function:

define :method apply_two_arg(f:midclosure, x, z);
    apply_three_arg(f, x, middlearg(f), z);
enddefine;

and lastly, having defined the behaviour of our new
object, we need to actually create it:

instance midclosure middlearg = "psi" endinstance -> doublet;

and we can use this in a similar way:

apply_two_arg(doublet, "chi", "omega");
** [first chi second psi third omega]

If you put all that example code together you will agree, I
think, that when pop closures can be used, they certainly
encapsulate a lot of functionality!! But don't, for one
minute, think they are *simpler*. All that the objectclass
stuff is doing, is making explicit, and bringing to the
surface, something very similar to what is actually going
on inside the poplog virtual machine for pop closures. The
difference is that the "class" of pop functions is already
implicit in the language, as is the "class" of closures.

There are some other ways in which the objectclass stuff
looks ugly because of syntactic restrictions. For example,
in C++ I could have used the same name "apply" for both
the apply methods, instead of the clumsier "apply_two_arg"
and "apply_three_arg". In Java, I needn't have declared
the class "midclosure" -- I could have used an anonymous
class. And so on.

But the bottom line is that an apparently "simple" mechanism --
the pop closure -- is actually a very powerful abstraction,
which hides a lot of behind-the-scenes complexity. And that
is part of what makes it so useful.

Jonathan

--
Jonathan L Cunningham



Sat, 01 Nov 2003 19:01:28 GMT  
 filenames, argument list separators + gsl extension


Quote:


>>Part of that is syntax; part of it is the Poplog VM. The latter controls
>>what kind of things can be said; the former controls how *easily* they
>>may be said. For example, Pop's syntax for closures is pretty easy to
>>write and read; it gets used a *lot*. It's not perfect (I think Spice
>>"holes" will turn out better, but they've not been used in anger), but
>>it's easier than explicit lambda-expressions. If it's clumsy to write,
>>*it doesn't get used*.
> 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 )

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

[comments re: objectclass deleted]

--
Chris "?2 - ?1, for example" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Sat, 01 Nov 2003 20:51:10 GMT  
 filenames, argument list separators + gsl extension
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Quote:

> Date: 15 May 2001 12:51:10 GMT
> Organization: Hewlett-Packard Laboratories, Bristol, UK




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

Quote:
>     f(% ?1, arg, ?2 %)

That would then nicely generalise to allow all these:

Quote:
>     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 %)

Quote:
> 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

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html



Sun, 02 Nov 2003 01:13:47 GMT  
 filenames, argument list separators + gsl extension


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


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

Quote:
> 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).

Quote:
> 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


which is one way of writing the equivalent of

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

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

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

Quote:
>> 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!]

Quote:
> 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.)

Quote:
> 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



Sun, 02 Nov 2003 13:42:49 GMT  
 filenames, argument list separators + gsl extension


        (Aaron Sloman See text for reply address) writes:

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

(twin wrote)

Quote:
> 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


> which is one way of writing the equivalent of

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

or using Aaron's syntax

    conspair(% x, ?1 %)

(aaron wrote)

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

I think I do now.

You mean that just as some people would interpret F(A)(B) as F((A)(B)), not
(F(A))(B), because they think of the last thing being the argument,
and the *immediately* preceeding thing as being the F, they might
be confused trying to find the closest enclosing holey expression?

[How real is the example, by the way?]

That's possible. We'll have to see what happens. Incidentally, I've
always found these prefix application chains to be an invitation to
confusion and tedium, which is why I'm so chuffed about the infix-call
syntax I introduced in Pepper (and used heavily in Pop) and borrowed
into Spice, although the natural translation of the first ikk above:


turns out not to be significantly better.

I'll stop now before I realise I'm talking like a salesman.

--
Chris "Spice does have *semantic* benefits too ..." Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Sun, 02 Nov 2003 15:31:46 GMT  
 filenames, argument list separators + gsl extension
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]

Quote:

> Date: 14 May 2001 22:04:16 GMT
> ...
> > > Is this matter related to pop11's failure to detect the missing separator
> > > in the local var. declaration, below ?  My understanding is that comma
> > > (only) is a a valid separator here ?

> > >     define listify(list) -> result;
> > >               vars next   tail;

> > HELP VARS says:

> >     For the present, commas may be omitted except after an initialisation,
> >     but it is recommended that they be used.
> Thanks. That reduces a very uncomfortable feeling.
> But I find such ambiguity unacceptable in computing.

This is not so much ambiguity as excessive tolerance.

The reason why commas are not required is that Pop-11 is essentially a
very old language, born around 1969, reborn as pop2 around 1971, then as
Pop-11 around 1975 and extended in many ways at various times since
then.

Originally "vars" declarations used ONLY spaces as delimeters, and
function definitions started thus:

    function foo x y z;

Gradually more structured syntax evolved

    define foo(x, y, z);

Some of the older more tolerant syntax gradually dropped out of use,
but so much code was written without commas separating variable
names in declarations, and so many tutorial files, books and other
documentation had examples like that, that it would probably have
caused a lot of trouble and annoyance to insist on commas.

I now try to use commas rather than spaces everywhere in declarations in
my code and documentation (e.g. throughout the primer), and I think it
might be a good idea from some time in the future to phase out tolerance
of declarations without commas. I think this would lead to easier
compile time detection of some programming errors.

However, changing all the libraries and teaching documentation to
conform would require some effort. Some of it could be automated.

But this is a small point compared with other changes required in
pop-11 and poplog (e.g. remove dependence on so many environment
variables).

Aaron

- Show quoted text -

Quote:

> > and I'd assume it's mostly a backward-compatability relic from the days                  
> > of POP2.                  
> These apparently trivial details cause 'failure'.                  

> > No, there's no relationship between the one and the other.                  


> > (c) My own feeling is that although the recent discussions of syntax for                  
> > various types of data-constructing expressions are interesting and                  
> > could, if they had occurred around 1970, have led to much better syntax                  
> > for the pop family, they are far less important for real users than                  
> > other "semantic" issues like the availability of powerful libraries that                  
> > extend what you can easily do, the availability of new debugging and                  
> > development tools, etc.                  

> Yes, consider the cost/benefit.  The discussed changes seem to me                  
> (a beginner) to be drastic, hence potentially disasterous.                  
> Inevitably the greatest added value per effort (especially for beginnners                  
> usage) is acheived by mundane tasks - which no one want's to discuss.                  
> eg. "set up a system" (NOT do the job) whereby new users report typos                  
> in the tutorials, which are fixed.                  
>  ...                  
> > By comparison with "semantic" extensions of the above types, I believe                  
> > changes to the syntax of existing constructs are really of marginal                  
> > importance!                  

> Very important, marginal value, hence not recommended to change.                  
> ...                  
> > Is anyone interested in forming a collaborative project to provide                  
> > the gsl extension to pop-11???                  

> Are the extensions just mathematical facilities ?                  
> Can you list some example(s) ?                  

> Chris Glur.                  

====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html


Wed, 12 Nov 2003 18:35:57 GMT  
 filenames, argument list separators + gsl extension
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]


an interesting message about closures and objectclass instances

Quote:
> Date: Tue, 15 May 2001 11:01:28 GMT

....(lots cut out) ....

Quote:
> But the bottom line is that an apparently "simple" mechanism --
> the pop closure -- is actually a very powerful abstraction,
> which hides a lot of behind-the-scenes complexity. And that
> is part of what makes it so useful.

Jonathan,

I liked your tutorial on closures and objectclass. I have temporarily
saved it in

    http://www.cs.bham.ac.uk/~axs/misc/closures.and.classes.txt

to which I'll append this message.

One day I'll turn it into a TEACH file on closures and class instances.
If and when I get round to doing this, I'll let you have a chance to
edit it!

A few small points.

Quote:

> There are some other ways in which the objectclass stuff
> looks ugly because of syntactic restrictions. For example,
> in C++ I could have used the same name "apply" for both
> the apply methods, instead of the clumsier "apply_two_arg"
> and "apply_three_arg".

This could be handled by using class_apply. From REF KEYS:

| class_apply(key) -> apply_p                                  [procedure]
| apply_p -> class_apply(key)
|     ....
|             The updater of class_apply assigns the procedure apply_p  to
|         be the apply procedure  for the class  key key.

This means that instances can be treated as if they were procedures,
and when they are applied to arguments the class_apply procedure for
the Pop11 class to which they belong will be run.

Every pop11 entity has a class represented by its datakey

    datakey("cat")=>
    ** <key word>

    datakey(hd)=>
    ** <key procedure>

    datakey(sqrt(-1))=>
    ** <key complex>

    datakey(-1)=>
    ** <key integer>

which holds generic information about entities in that class,
including what should be done if you try to treat that entity
as a procedure, e.g. when applying a list to a number.

    [cat dog mouse](2)=>
    ** dog

This is not to be confused with objectclass classes. See
    HELP CLASSES
    REF KEYS

REF OBJECTCLASS says that the method apply_instance is the default
class_apply for objeclass instances.

So you can redefine it as a method that does different things for
different classes. So with a little extra work (illustrated below) you
can then replace

    > apply_two_arg(doublet, "chi", "omega");

with

    doublet("chi", "omega");

So unlike c++ you will not even need to use "apply" to run your
objectclass-based closures!

Quote:
> In Java, I needn't have declared
> the class "midclosure" -- I could have used an anonymous
> class. And so on.

I don't know how anonymous classes work in Java, but I guess there are
at least three reasons for using anonymous classes:

(a) privacy: the class and its methods can be accessed only in the
    scope of the text where the class is introduced.

(b) efficiency because global identifiers don't need to be created

(c) syntactic convenience

In objectclass (a) and (b) can be achieved by using lvars or lconstant
in the class definition, and using lblock  endlblock to restrict the
scope of the lexical identifiers. An example is given below.

Maybe (c), the extra syntactic convenience, could (if desired) be
achieved by defining new syntax words or macros to do the equivalent of
all this.

Anyhow here is an example illustrating the use of apply_instance,
lconstant and lblock, in connection with your example (slightly
simplified):

Suppose we have a procedure for which we wish to create a closure that
fixes the middle argument:

define apply_three(x, y, z);
       [first ^x second ^y third ^z]=>
enddefine;

uses objectclass;

;;; start the lexical block
lblock

    ;;; define our new "anonymous" class
    define :class lconstant midclosure;
        slot middlearg;
    enddefine;

    ;;; change the class_apply for its instances

    define :method apply_instance(f:midclosure);

        ;;; get two arguments from the stack
        lvars x, z;
            -> (x, z);

        apply_three(f, x, middlearg(f), z);

    enddefine;

    ;;; create an instance inside the lexical block
    define :instance doublet :midclosure;
        middlearg = "psi";
    enddefine;

endlblock;

;;; Then test that doublet works as expected, i.e. as a closure
;;; of apply_three

doublet("chi", "omega");
** [first chi second psi third omega]

doublet("cat", "dog");
** [first cat second psi third dog]

Q.E.D.

Compare this standard Pop-11 version which returns a closure of an
anonymous procedure which runs apply_three:

vars doublet2 =

    procedure(y);
        procedure(x, z);
            apply_three(x, y, z)
        endprocedure;
    endprocedure("psi");

doublet2("cat", "dog");
** [first cat second psi third dog]

or, simplest of all, using partial application

vars doublet3 =
    procedure(x, z, y);
            apply_three(x, y, z)
    endprocedure(% "psi" %);

doublet3("cat", "dog");
** [first cat second psi third dog]

Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK

PAPERS: http://www.cs.bham.ac.uk/research/cogaff/
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html



Mon, 17 Nov 2003 19:47:06 GMT  
 filenames, argument list separators + gsl extension


Quote:
> I don't know how anonymous classes work in Java,

So far as I can tell, to allow you to implement things with almost
all of the semantic effects of closures with almost none of the
syntactic convenience.

Quote:
> but I guess there are
> at least three reasons for using anonymous classes:

> (a) privacy: the class and its methods can be accessed only in the
>     scope of the text where the class is introduced.

Well, nested classes do that; what anonymous classes do is allow you
to write a class "in-line" at the point where you `new` it, rather
as a procedure ... endprocedure expression allows you to write a
procedure expression where you need it rather than as a definition.

Quote:
> (b) efficiency because global identifiers don't need to be created

Certainly not true for Java classes!

Quote:
> (c) syntactic convenience

If only.

Well, anonymous classes are more convenient than named classes when
they're appropriate. For small values of "more".

(Actually there are three interacting aspects to this in Java: nested
classes (if not static) have some closure-like properties, as their
instances can "see" the instance of the surrounding class that "owns"
them; nesting classes does scope control; and anonymous classes allow
you to write a class body after "new" so you don't need to park a
class definition a "long way off" in the text.)

I'm not sure the existing language design and implementation constraints
(eg it must compile to code that works on the older JVMs) left them
much room for manoeuver).

--
Chris "but I strongly dislike the result" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Mon, 17 Nov 2003 20:56:17 GMT  
 filenames, argument list separators + gsl extension
On Thu, 31 May 2001 11:47:06 +0000 (UTC),

Quote:

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


>an interesting message about closures and objectclass instances
(snip)
>I liked your tutorial on closures and objectclass. I have temporarily
>saved it in

>    http://www.cs.bham.ac.uk/~axs/misc/closures.and.classes.txt

Fine - if it seems useful/interesting to anyone I'm glad.

Quote:
>A few small points.

(snip)
>This could be handled by using class_apply. From REF KEYS:

(snip)
>This means that instances can be treated as if they were procedures,

I'd forgotten about class_apply - thanks for the reminder.

Quote:
>Every pop11 entity has a class represented by its datakey
(snip)
>which holds generic information about entities in that class,

Yes. John Gibson was, ISTM, gradually evolving the innards of
poplog into being an object-based language. This is not the
same as an object-oriented language. I wonder if this is
still the terminology used for this distinction? Jargon
seems to change faster than the underlying concepts.

The distinction I'm talking about mostly boils down to
that object-oriented languages support inheritance, whereas
object-based ones don't, as I understand it. It was the
failure to support inheritance in various Microsoft
distributed object models that was the biggest technical
criticism of them. Not that it stops them being used ...

Quote:
>This is not to be confused with objectclass classes. See

which, of course, does support inheritance, and is
properly object-oriented.

Quote:
>> In Java, I needn't have declared
>> the class "midclosure" -- I could have used an anonymous
>> class. And so on.

>I don't know how anonymous classes work in Java, but I guess there are
>at least three reasons for using anonymous classes:

Chris Dollin replied to this, so I'll continue in a follow-up
to his post.

Jonathan

--
Jonathan L Cunningham



Mon, 24 Nov 2003 20:40:00 GMT  
 filenames, argument list separators + gsl extension

Quote:


>> I don't know how anonymous classes work in Java,
(snip)
>> (b) efficiency because global identifiers don't need to be created

>Certainly not true for Java classes!

Is that right? I don't know what the output of a Java compiler looks
like, and you do say

Quote:
>I'm not sure the existing language design and implementation constraints
>(eg it must compile to code that works on the older JVMs) left them
>much room for manoeuver).

so I can believe it, but it is not obvious that an anonymous class
would need a global identifier, so I may be misreading an ambiguity
in what you wrote.

(Or, to put that another way, I bet it is possible to for a
sufficiently clever Java compiler to avoid generating a global name,
for sufficiently large values of "sufficiently clever" :-).

Jonathan

--
Jonathan L Cunningham



Mon, 24 Nov 2003 20:40:04 GMT  
 filenames, argument list separators + gsl extension


Quote:



>>      (Aaron Sloman See text for reply address) writes:

>>> I don't know how anonymous classes work in Java,
> (snip)
>>> (b) efficiency because global identifiers don't need to be created

>>Certainly not true for Java classes!

> Is that right?

For suitable values of the term "global identifier".

Quote:
> I don't know what the output of a Java compiler looks like,

It's a class file, as documented in the JVM spec. It's *not* that hard
to parse, it turns out (working with the result, that's different).

Quote:
> and you do say

>>I'm not sure the existing language design and implementation constraints
>>(eg it must compile to code that works on the older JVMs) left them
>>much room for manoeuver).

> so I can believe it, but it is not obvious that an anonymous class
> would need a global identifier, so I may be misreading an ambiguity
> in what you wrote.

JVM classes all have names. There's no way to express in the class-file
a class that has no name. The compiler *generates* a name for the class:
if class ``Legs` is nested inside a class called `Spoo`, then the class
is given the "global name" `Spoo$Legs`.

[A Java program cannot utter such a name, but that's no big deal given
the ability to hack classfiles.]

Recall that each class gets its own classfile (I kid thee not), and
classfiles have to be fetched by name, so getting a class without a name
would be ... interesting.

Quote:
> (Or, to put that another way, I bet it is possible to for a
> sufficiently clever Java compiler to avoid generating a global name,
> for sufficiently large values of "sufficiently clever" :-).

The translation rules are mandated by the specification, if I recall
correctly, so such a compiler would be non-conforming. I think "cleverness"
blends into "psychic" at this point. We need a quantum compiler.

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html



Mon, 24 Nov 2003 21:00:57 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. filenames, argument list separators

2. GSL collaboration and (and GSL Manual contents)

3. Adding PC Filename Extensions to Macintosh Filenames

4. Using tab as a separator in list directed read

5. arguments(filenames) with spaces in them

6. Locale-sensitive list separator under Windows

7. Filename extensions for Forth source

8. gvim with .F90 filename extensions?

9. alternate filename extension question

10. filename extensions

11. newbie: filename without extension

12. how to get a list of filename

 

 
Powered by phpBB® Forum Software