Firth
Firth copied to clipboard
hikari-no-yume
Lists
Alright, so we'd add list function that takes another function.
[ 5 5 add. 20 ] list.
Calling list would invoke the function and would then read out all the values, in this case 10 and 20.
List is a new type list (like specified in the spec) and when typeclasses are there, we could add some functions:
/size [ 5 5 add. 10 ] list. get. print. ; 2
The type and the list function are already in the spec, I just haven't gotten round to adding functions to manipulate them, and I haven't implemented list yet. Same thing with strings.
Since strings could be thought of as just lists of codepoints, functions that operate on lists should work on strings too, where it makes sense.
Shouldn't we wait to add those functions until typeclasses are working?
Using typeclasses for this would also fix the problem of too many functions in global scope.
For one of my other projects I've been using Haskell again, but initially I was going to go for PureScript. While looking into PureScript, I found out about problems it's had with its list type. They made it be a JavaScript array, which is a similar to the list type currently proposed for Firth. JavaScript's Array is what it sounds: a dynamic array, This means it has O(1) indexing and (typically) O(1) append, but getting the "tail" (think Lisp's cdr or Haskell's tail) is O(n), and prepending is also O(n). This is bad because taking the "tail" of a list is a frequent operation in functional code with recursion, as is prepending. On the other hand, list type in Haskell and Lisp is a linked-list: O(n) indexing and appending, but getting the tail and prepending is O(1).
So now I think what Firth actually needs is two sequence types: list and array. The former would be a singly-linked list, the latter is a dynamic array. The syntax would be the same:
[3 2 1] array.
[3 2 1] list.
See: https://en.wikipedia.org/wiki/Template:List_data_structure_comparison
Ideally you implement array as a ring buffer, so prepend can also be O(1). But with compiling to JS you're at the mercy of the implementation. I'm not sure, but I think Firefox implements it this way.