[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hierarchical lists, again



[i agree with what most of Noah wrote.  i'm just in a disagreeable mood.]

> I am skeptical that this should be added to initial.es, especially right
> away.  It is easy for people to define for themselves if they really want
> or need such a feature.

while it's easy to write, you can't just depend on it being there for now.
it's useful enough .

for example, result could be written

	fn result { return $* }

and everyone could have their own version.  i did that for a long time.
(if you look at my .esrc from the first es distribution, the I function
(as in identity) was in there.  it moved into initial.es when i started
needing it inside initial.es, but i think that it was a good thing to
put in initial.es because it is so generally useful.

> Personally, I want to play around with the idea
> myself and see if I find preferable ways of implementing hiearchical lists.

that's a good reason.  perhaps.  on the other hand, if ``wrap'' were to
be included with Harald's semantics in 0.9, it doesn't preclude a ``seal''
function coming in later with new semantics, and wrap is of sufficient
usefulness that i'd like to be able count on it being around.

> It must be obvious by now that I think es should be stripped of many
> builtin features, rather than adding more.

and i agree.  on the other hand, it's hard to cut.  (i'm sorry to
the people who replied to my request for proposed deletions for
not having said anything about them.  i really wanted to see more
suggestions before i said anything.  i'll reply to Noah's note
to the list soon.)

> The only two things I really
> want added to es are some sort of simple arithmetic capability (beyond
> Church numerals :-)) mainly for doing faster manipulation of arrays (it's a
> shame that deleting the last element of an array requires looping over the
> entire array);

	; x = a b c
	; let (y = 1 $x) x = $y(2 ... $#x)
	; echo $x
	a b
	; 

not that arithmetic wouldn't be clearer, but it can be done.

by the way, do other people think of them as arrays?  i've always
considered them lists, but i'll admit that the semantics feel more
like arrays than lists, implementation notwithstanding.

> and preservation of closures across invocations of es, which
> ought to be possible by tagging closures with some ID.  The latter I don't
> even think is a feature request---it's simply a bug in the current
> implementation that it doesn't do so already.

i'll 90% agree that it's a bug, but it's also a feature request in my mind.
possibly in 0.9.

paul