Re: comments on my design of a new language?

> Typing is likewise kept simple. All the expected numeric types will
> > exist, plus strings and the function type, and that is it. I am not
> > planning on allowing user-defined types. I suspect many will dislike
> > this aspect, but it has numerous advantages, which I will refrain from
> > citing here.
> Maybe we're getting into semantics here, but it seems to me you actually
> have a couple other types. You have a "dictionary" type, which can be
> indexed by a string or a regular expression, and is unordered. You have a
> "list" type which has no direct indexing facility, but which is ordered. You
> also have a regular expression type.

You are right. There should be a regular expression type. I had thought
about it but didnt mention another structure, a sort of tree list. This
would be a temporary container (a variable would not be able to refer
to such a structure). It works on the same principles as the arrays,
but is strictly one-dimensional. There is no separate dictionary type,
though. Trees are essentially nested dictionaries, and this is the only
place where unordered uniqueness occurs.

> Occasionally, you seem to treat a list of length one, and a primitive scalar
> value, as being indistinguishable. Other times, they are treated very
> differently.

I was originally going to treat scalars and unit lists equivalently,
but I realized that would screw up multidimensional array processing so
I now distinguish. It is quite possible I have not thought through all
of the cases. Could you cite a instance of inconsistent treatment?

[snip]

> What are the rules for when the number of assignment values differ from
> the number of receiving values? Since you seem to be allowing for arbitrary
> regular expressions for looking up nodes, the programmer may not know how
> many nodes will match a particular regexp lookup.
> Do you have some sort of facility for programmatically differentiating
> between a variable which contains a dictionary, and a variable which
> contains a primitive value? Is there a way to get all keys of a dictionary?

I think you seem to think regular expressions return an unordered
dictionary, but they dont. They return tree lists or arrays depending
on whether they are operating on terminal nodes or not. Regex engines
search from left to right through text, so there is a natural ordering.

I thought a nice way to get all children of a node would be with empty
trailing braces.

node{}

This would return a fixed order tree list as does a regex call, only
the order wouldnt be known by the caller.


> When "a copy is made", is it a deep copy, making a copy of the entire tree
> that a variable may be the root off, or a shallow copy, creating a single
> new dictionary, but otherwise each child of that dictionary now has an
> additional reference to them?
> Can a dictionary contain a reference to itself as one of its values? Can you
> compare too dictionaries for equality? If so, are they equal by value, or by
> reference?

This is something Im still thinking about. Probably assignment would
always copy deeply. The "is" statement is meant to be the only method
of referencing outside of !funcs and for loops. I hadnt thought about
circular references. Im not sure of the implications...

[snip]

> What about the following?
> a = x!do1():do2()!do3():do4()!do5()
> Here, do1() modifies x, do2() acts on a copy of x, and that copy gets stored
> into a. do3() then modifies the copy. do4() then makes a copy of that copy.
> do5() then modifies the copy of the copy, but the value is lost, because it
> doesn't get stored anywhere.

I dont see why you would think the value would get stored to a after
do2(). I would want assignment with = to always be the last operation.
I want to thank you for the example, though. The system does allow some
wacky operations that a sane programmer would probably want to avoid,
but its good to test the limits.

> I'm not sure that these rules are consistent. It seems like you have two
> types of values here: scalars, and lists. If you add a list to a list, the
> length of each list has to be the same, and each element from the two list
> are added together pair wise. If you add a list to a scalar, then the scalar
> is added to each element in the list.

Yes this is correct. It has been proven consistent elsewhere, eg
Python's numarray lib.

[snip]

> [[1, 2], [3, 4]] + [1, 3] = [[1, 2] + 1, [3, 4] + 3] = [[1 + 1, 2 + 1], [3 +
> 3, 4 + 3]] = [[2, 3], [6, 7]]
> This last one doesn't match your example, which says that the result should
> be [[2,5],[4,7]].

They seem to match to me. I really am just stealing the behavior
directly from numarray. If it works their, it will work in my language;
if not it wont.

> > flavors = ['apple', 'peach cobbler', 'pecan']
> > pie{flavors}:eat # eat called with each flavor

> Here, I'm assuming "pie" is a dictionary. Previously, you gave examples of
> dictionaries being indexed by strings or by regular expressions. What does
> it mean for a dictionary to be indexed by a list? What about by a list of
> lists? Is it possible for a dictionary to be indexed by a dictionary? And
> what about a dictionary of dictionaries? What about a dictionary of lists?
> What about a list of dictionaries?

pie is a tree, which is like a dictionary yes. I had one example that
used lists to access a tree:

animals{['pig', 'cow']} = 'swine', 'bovine'

On deeper consideration, I think maybe what should happen is that {}
access should allow multiple values directly rather than a list. So
this would work:

animals{'pig', 'cow'} = 'swine', 'bovine'

Better still, I can allow both types and just flatten it into a single
list. Even combinations:

pie{flavors, 'lemon maragne'}:eat

Multidimensional arrays should produce an error.

> [snip]

> The it keyword. it is a special variable which refers to the current
> > iteration of the left-hand side of an assignment or a function call
> > (before the :colon) or the whole thing if it is a singleton.
> # filtering
> > old = [1,2,3,4,2,3,1,2,3,1]
> > new = old if it != 1 # -> [2,3,4,2,3,2,3]
> # numbers can be searched as strings with pattern-matching
> > new = old
> > new<1>!pop # -> [2,3,4,2,3,2,3]

> new is a list, so apparently you can run a regular expression on a list, and
> only get the elements which match. That is, "new<1>" in the above, would
> probably be equal to the list [1,1,1].
> The statement "new<1>!pop" should then call pop(), passing to it the list
> [1,1,1], and then replacing that list with whatever it is that pop()
> returns.
> You seem to be implying that pop should instead be called on the original
> list called "new". I think the syntax should then be:
> new!pop(<1>)
> Where you're calling pop() on "new", and passing to it a regular
> expression as an argument. The function pop() would then iterate through the
> list, and remove any elements which match the regular expression.

You are absolutely right - stupid mistake.

> But what if the children of "new" were something other than strings or
> numbers? What if they were lists, or dictionaries, or regular expressions
> themselves? How do you match a regular expression against a regular
> expression?

Functions only work on literals, literal arrays, or tree lists that
have no nonterminal children. As for regular expressions, you got me
thinking. Though it is not something most people would have use for, I
have always wanted a mechanism for generating a random string that
obeys a regular expression rule. Perhaps when a regex is used where a
string is expected, I could have it do just that.

.

Relevant Pages

  • Re: comments on my design of a new language?
    ... Trees are essentially nested dictionaries, and this is the only place where unordered uniqueness occurs. ... Lists are ordered? ... Though it is not something most people would have use for, I have always wanted a mechanism for generating a random string that obeys a regular expression rule. ...
    (comp.lang.misc)
  • Re: comments on my design of a new language?
    ... > exist, plus strings and the function type, and that is it. ... indexed by a string or a regular expression, ... > dictionaries, that terminate with literals, or (possibly ... and lists. ...
    (comp.lang.misc)
  • Fast Data Comparison (dict v. list. v string)
    ... many comparisons to fixed-size lists of fixed-length strings. ... my implementation uses dictionaries to store each string. ... all I have to do to compare the two ... it appears that strings are constant as I can't assign individual ...
    (comp.lang.python)
  • Re: objects as mutable dictionary keys
    ... for lists, and it isn't defined by default for user ... >> dictionaries recently, and the mainstream opinion was that dictionary ... >> keys must not be mutable, so lists are not allowed as dictionary keys. ... > - Dictionary lookup with list literals would be impossible. ...
    (comp.lang.python)
  • Re: Pre-PEP: Dictionary accumulator methods
    ... ## Using only built-in function as arguments makes it ... > * The getidiom requires two dictionary lookups of the same key. ... > dictionaries). ... most uses I've seen are with lists. ...
    (comp.lang.python)
Loading