> maps can easily represent lists but not vice versa
Obviously false, as demonstrated by Lisp, with which the author must be familiar.
The problem with maps as a basis for a programming language is that you need expressions to have one entry point which says what expression this is. In a sequence, an obvious choice is the first element, or sometimes the last. This is why YAML-programming expressions in Ansible in fact work exactly like regular function calls, with their “- function: argument argument” syntax (which Ansible authors seem to not notice). ‘Misc’, of course, also has to choose ‘0’ to represent the expression entry point.
I think this syntax is translatable one-to-one to old Lisp syntax, probably with keyword arguments.
Wouldn't it be fair to say a proper map can (more) directly represent a list, while a list can only be used as the underlying implementation of a map?
Specifically for lisp, a list is a sequence of cons cells, and you would have to do a linear search to look up a value by key - thus, it can function as a map from an Api point of view, but not in terms of performance?
That's why the common lisp "map" is a hash table, not a list?
> while a list can only be used as the underlying implementation of a map?
I certainly wouldn't advise that. We're talking about language syntax here. Lists serve alright for maps in the syntax (personally I like Clojure's curly-brace literals), but I sure hope that the implementation uses hash maps or something like that.
I also have no idea why lists have to be linked-lists and made of cons cells. Lisps working on top of pre-existing environments, like Clojure, don't seem to bother with that requirement, so it looks like it's just an idea from the stone age of computing.
I guess it can do so. I don't really understand why one would want to ‘base’ the language on maps to promptly go back to lists for putting these integer-keyed maps in. Where's the ‘based on maps’ part then?
It would be really map-based, in my book, if it used named arguments for every function—though that would be incredibly cumbersome (ahem ObjC cough). As it is, it's just regular Lisp but with map keys having colons on the right instead of the left.
A map with integer keys is closer to an array than a list.
I'm not sure I follow your arguments - you seem to be talking of "lists" as some sort of string syntax, possibly as some form of abstract syntax - but either way separate from the abstract data structure?
That's not how I read the comment from the misc page - they seem to be talking about the ADT - much like clojure chose to not use lists made from cons pairs?
Since there isn't any traversal when looking up an element n, I guess the best "short hand" would be to call it an array - it's an array of pointers to objects on the heap.
In a similar vein, "lumen" is a small lisp/scheme dialect that experiments in a similar direction. It replaces lisp's lists with lua/javascript's "arrays and dictionaries at the same time" objects. (Self-hosted, compiles to both javascript and lua.)
I like Lua, and lisps, and I write a lot of JavaScript, but I don't understand why I would ever need 1 language that compiles to both Lua or JavaScript. Something like Nim compiles to C or JavaScript, so you have 1 lang for you high and low(er) level code. Just seems weird to target those 2 particular languages.
This made me think of Racket's syntax objects, which are also more than simple lists. They contain a lot of information like source and position, but can also contains arbitrary properties (like a map, in a sense). See https://docs.racket-lang.org/reference/stxprops.html
I don't know if there is any relationship between authors. The idea of applying the lessons and benefits of XML to imperative programming to form a kind of meta language or meta-friendly language is present.
I always found the excessive usage of linked lists in lisp style languages to be rather odd. It's about the worst possible data structure for performance unless you have a sufficiently smart complier... I think it's used for the beautiful simplicity of the language and not because it's actually a good way to compute things.
I think it's partly due to many university lisp courses focusing on the symbolic end of lisp/programming languages - rather than on the performance side of computing theory.
For common lisp, for example, it's probably fair to say that an over use of lists is "wrong" in the general case (ie, if your problem is data driven, which would probably be the case in most applications/utilities).
Now, if all you're doing is improving the language/honing a DSL - the you'll probably be using lists a lot, as that is what constitutes the abstract syntax tree you're manipulating.
See this for a brief discussion on collections in common lisp:
It's probably okay with this thing but in general don't do this. "wget totallynotmalware.exe; totallynotmalware.exe".
Note to self: if I wanted to distribute Java malware to the HN crowd this is exactly how I would do it: write a minimalist, nerdy topic that requires an applet to run, knowing that my audience will happily find a work-around, like the above.
Yeah, I'm assuming that people know what they are doing and taking the necessary precautions themselves when running untrusted code. I'm not gonna add "Run this in a virtual machine" every time I mention some software.
But your reminder is good for the newcomers around I guess.
Befunge is a stack-based, reflective, esoteric programming language. It differs from conventional languages in that programs are arranged on a two-dimensional grid. "Arrow" instructions direct the control flow to the left, right, up or down, and loops are constructed by sending the control flow in a cycle. It has been described as "a cross between Forth and Lemmings."[1]
Obviously false, as demonstrated by Lisp, with which the author must be familiar.
The problem with maps as a basis for a programming language is that you need expressions to have one entry point which says what expression this is. In a sequence, an obvious choice is the first element, or sometimes the last. This is why YAML-programming expressions in Ansible in fact work exactly like regular function calls, with their “- function: argument argument” syntax (which Ansible authors seem to not notice). ‘Misc’, of course, also has to choose ‘0’ to represent the expression entry point.
I think this syntax is translatable one-to-one to old Lisp syntax, probably with keyword arguments.