🚀 go-pugleaf

In article <ROCKWELL.92Apr7005432@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
|I'm not sure I understand the questions.  J hasn't been around long
|enough for there to be a particular definition style.  For example, a
|style which uses a separate file for each function definition would
|look quite different than a style which uses scripts, with literal
|text quoted in-line.  The first would look somewhat like a c program
|with various modules and a makefile, the second would look somewhat
|like a shar archive (or, perhaps, a bit cleaner).  And if the user is
|driving the definition process from emacs, they'll just look like
|text.  And, there are other definition styles.

This seems rather odd, given that as a programmer, I see my whole
*job* as being writing functions. A language that has everything BUT a
syntax for writing functions, now, is an odd one. (Don't get me wrong;
I understand the difficulty. A good syntax for function definition is
probably the single hardest "surface" feature to get right. But not
even trying? ;-).

|   Oh, I realise there's still a missing piece of info: if you use =:
|   in a scope that has introduced a new name textually identical to
|   that on the left of the assignment, what gets updated? The local,
|   the global, or both? If you are really LEXICALLY scoped, it ought
|   to be the local, but what if that defining scope has already
|   exited? Is that handled correctly?
|
|Well, the global definition is updated.  If you want the local
|definition to be updated you can use '=.'  If there is some local
|definition shadowing the global definition, you can always create a
|new context where the local definition does not exist.

But wait, doesn't that contradict your previous statement? If the
GLOBAL value is updated, then in what sense is anything ever
"shadowed"? (Or did you mean you do this for read purposes?).

|I might define an example of this as follows:
|
|example =. (here_is '.') : ''
|.  test=. 3
|.  test=: 4
|. 'local  ' label test
|. 'global ' label 'test':'' 0
|.                               NB. return an empty result
|
|Then, if I used
|   example 0
|The routine would display:
|local  3
|global 4
|
|And, on exit, 'test' would have the value 4
|
|By the way, I'm presuming that the definitions of 'here_is' and
|'label' are not pertinent to this discussion.  Also, 'NB.' introduces
|a comment.

I think they are, because I think they're absolutely necessary for a
mere mortal to understand your example. Fortunately, not having such
problems myself, I figured it out ;-). Gross.

But I think this rather makes the point: it isn't a statically scoped
language in any conventional sense, or "global", being defined INSIDE
the scope of local test, would get the currently-in-scope value of
"test", viz: 3. Of course, in order order to implement this, you'd
have to associate a lexical environment with evey string - something
that you obviously wouldn't want to do, which is what prompted me to
ask the question.

So the situation ACTUALLY is that there are local scopes and there are
global scopes, and the ONLY scope nesting is that a global definitions
are, if not shadowed, visible locally. I don't think that's either
lexical or dynamic, so much as none at all! - if local scopes NEVER
nest, how can you even discuss HOW?

Ok, to be fair, *can* you encode the programme (using infix "." for
lambda abstraction)

	f = (x . y . x + y)

(the idea being that (f 1) is the increment function and (f _1) is the
decrement function, e.g.) in such a way that the compiler doesn't get
invoked at runtime?

Failing that (because many languages refuse to do that one) what about
the harder to write but easier to implement:

	f = ((x , g) . g (y . x + y))

which gets a similar effect with a callback? "," here is the pairing
operator, of course.
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
stephen@estragon.uchicago.edu                    University of Chicago
----------------------------------------------------------------------