Re: Feature request: hiding upvalues

[Sean Conner <sean@...>]

It was thus said that the Great Philippe Verdy once stated:
> Le ven. 16 nov. 2018 à 23:04, Sean Conner <sean@conman.org> a écrit :
> 
> > Oh, then there are the various LISP machines, made in the late 70s---they
> > had tagged memory.  So in addition to the "data bits" part of the
> > "word", they also had "tag bits" that existly solely to impart type
> > information for the "data bits" part of the word.  So it's inaccurate to
> > say
> > that a "word" is just a collection of undifferentiated set of bits.
> >
> 
> Reread: you're reformulating what I told. I never said that a word was a
> collection of undifferentiated bits.

  You are correct.  I've gone back and carefully read through your walls of
text.  I read the following:

> In a classic CPU, the "word" has no distinctive type, it's just a
> fixed-size set of bits with arithmetic properties.

  In *many* CPU architectures, yes, a word is "a fixed-size set of bits" (I
have no idea how to interpret "arithmetic properties" so I'm leaving that
out), but not *ALL* CPU architectures are like that---that's what I was
talking about.

  You failed to understand what I meant by a LISP machine.  A LISP machine
is (or rather, was, they're no longer being manufactured but they still
exist and some even still run) a machine specifically built to efficiently
run LISP *at the CPU level*.  In fact [1]:

	The Symbolics 3600 family is a line of 36-bit single-user computers
	designed for high-productivity software development and for the
	execution of large symbolic programs. 3600-family processors give
	the user all the computational power associated with multi-user
	timesharing computers in a dedicated workstation. This is
	accomplished via a new and unique machine architecture that supports
	high-speed symbol processing operations directly in hardware. For
	example, *** every word in a Symbolics computer's virtual memory is
	tagged with data type bits ***---hence the name tagged architecture
	to describe 3600-family processors. The processor reads these bits
	to prevent illegal operations. As an added benefit, tag bits reduce
	the need for data type declarations in programs.

		(emphasis added)

> This is exactly the opposite that I said 
> 
> (and this is notably applicable to Lua "words" whose innner "bits" are
> differerentiated between datatype indicators and actual data
> 
>         (to represent numeric or string values or nil or table instances,
>         or functions; we have to add also "closures", i.e. the
>         instanciated contexts in which functions or coroutines are
>         operating)
> 
> :"words" in Lua are tagged objects with a small size 
> 
>         (fixed for each type, even if they are linked to other "words" to
>         create a larger structure, notably for strings, tables, functions,
>         and coroutines)
> 
> . The fact that these tagged objects have small fixed size allows storing
> them in a single "word" which are then countable and referencable, by the
> instruction set defined by the Lua VM.

  You're missing a closing parenthesis.  This is another reason your text is
hard to follow.

> So yes there's a valid concept of "word" in that context.
> 
> In Lisp the fundamental unit of information is the "node" in a binary
> tree: there's a differenciation only between the left and right links of
> the node (which is just an ordered pair), an in very few bits reserved in
> each link of the pair (allowing to differentiate a "nil" reference from an
> actual node reference, or a scalar value); both items of the pair are
> identifical and you could argue that the fundamental unit of information
> is one of these two items, but these items by themselves do not allow any
> contruction of larger data structures (lists, stacks, sets, tables,
> graphs...) and do not allow creating an ordered flow of instructions.

  I am not following you here.  I'm not even sure what you are trying to say
here.

> Instructions in any
> Lisp VM are themselves represented by these "nodes" (so the language
> naturally has reflection/instrospection capability, it can even transform
> "functions", i.e. what they will do when executed).

  Yes, there are other languages that can transform their own code---Ruby,
Forth, Smalltalk, even Assembly if you know what you are doing.

  -spc 

[1]	http://smbx.org/symbolics-technical-summary/