⚠️ Warning: This is a draft ⚠️

This means it might contain formatting issues, incorrect code, conceptual problems, or other severe issues.

If you want to help to improve and eventually enable this page, please fork RosettaGit's repository and open a merge request on GitHub.

==Common Lisp and Empty Lists?== The comment after the CL example seems to imply that it would not work with the example list given, which includes nested lists that contain an empty list. It would therefore not satisfy the task? --[[User:Paddy3118|Paddy3118]] 00:50, 17 August 2009 (UTC) :It works with the example given. The point is that if your list-of-lists-of-...-of-lists has as one of the intended leaf values ''a list'', you won't get the proper answer. This is true of any flattener, unless you mark the leaves as not-part-of-the-tree somehow. --[[User:Kevin Reid|Kevin Reid]] 02:32, 17 August 2009 (UTC) ::Hi Kevin, The intent is for nests of ultimately empty lists to not appear in the output at all. Doesn't lisp have some operation OP, where: lista OP listb = lista with the elements of listb concatenated ::And: lista OP emptylist == lista ::You should be able to complete a solution from that. The Python recursive solution is like that as the OP is list summation where: [1,2,3] + [4,5,6] = [1,2,3,4,5,6] ::And: [1,2,3] + [] = [1,2,3] :::--[[User:Paddy3118|Paddy3118]] 06:35, 17 August 2009 (UTC) :::That's not the problem. The code performs the specified task, but the task is to do something that is usually considered a bad idea, and symptom of poor design elsewhere, in CL. --[[User:Kevin Reid|Kevin Reid]] 03:10, 17 October 2009 (UTC)

==OCaml and Empty lists?== I am curious about the Ocaml entry and its problem with empty lists. Is their not some way of telling the type system to expect one or another of two types? Maybe [[wp:Algebraic data type]] (but I'm way out of my depth here) --[[User:Paddy3118|Paddy3118]] 00:58, 17 August 2009 (UTC)

Doh! I have just seen the OCaml entry which has indeed been extended with an Algebraic data type solution, but sadly it misses the deep nesting around 6 and a deeply nested, but ultimately empty sub-list. --[[User:Paddy3118|Paddy3118]] 06:45, 17 August 2009 (UTC)

==Examples of use missing== It would be good if all the language examples show how to flatten the list mentioned in the task description. C++, Common Lisp, E, Erlang, and Slate don't do this and R doesn't show example output. --[[User:Paddy3118|Paddy3118]] 02:36, 17 October 2009 (UTC)

: OK, I've now added the code to show flattening the given list in C++ (I already had written it anyway, because I needed it to test the algorithm). I guess you can see why I originally didn't. --[[User:Ce|Ce]] 08:14, 17 October 2009 (UTC)

Any more for any more? I note that the new Clojure example doesn't show the flattening applied to the example mentioned in the task either. Thnks, --[[User:Paddy3118|Paddy3118]] 18:32, 20 October 2009 (UTC)

==Omit TI-89?== Should the TI-89 BASIC entry be changed to an omit from ...? And maybe the text moved to this talk page? --[[User:Paddy3118|Paddy3118]] 02:36, 17 October 2009 (UTC)

Talk pages are for discussing the editing of the page, not additional content. (I also think that additional explanation of examples, as may have been done in a couple places, does not belong on talk pages.) As I wrote the entry I leave it to others to debate whether it should exist, but it definitely doesn't belong on the talk page. --[[User:Kevin Reid|Kevin Reid]] 03:02, 17 October 2009 (UTC)

== Line drawing in web browsers (J solution) ==

Out of interest which browser/platform combinations are not correctly displaying the line drawing in the [[Flatten a list#J|J solution]]?

I tested the display of the line drawing characters on IE 8 (Windows 7) and Firefox 3.63 (Windows 7 and Ubuntu) and they display fine there. --[[User:Tikkanz|Tikkanz]] 00:02, 2 June 2010 (UTC)

:::While the current display looks fine on most of the systems I tested it on, it looks wrong in Google Chrome 5.0.375.55 running on Vista. --[[User:Rdm|Rdm]] 02:33, 3 June 2010 (UTC)

:: Put the box into J highlighting again and it gets ugly since the digits are highlighted by GeSHi to be bold. That makes them wider than the surrounding characters, which throws off vertical line alignment. I have no clue what font the `<pre>` blocks are using; if I set them manually to Consolas or Courier New it all works fine. Ah, apparently it's Lucida Console. This probably can be fixed in the MW style sheet, considering that Lucida COnsole is the default choice for IE 8 at least for Latin monospace. There seem to be some fonts that work and some that don't. I agree, though, that everything should be in a single block. I made that change more of pragmatic considerations. In any case, a few sample images: [http://hypftier.de/dump/box-consolas.png Consolas], [http://hypftier.de/dump/box-courier-new.png Courier New], [http://hypftier.de/dump/box-dejavu-sans-mono.png DejaVu Sans Mono], [http://hypftier.de/dump/box-lucida-console.png Lucida Console] – that's all I have in monospaced fonts. Note that Consolas didn't have line-drawing glyphs in Vista; dunno whether that has been fixed in an update or so, but Windows 7's Consolas has them. Seemingly only Lucida Console has a different width depending on the weight, though (which makes it even more unsuitable as the default). —[[User:Hypftier|Johannes Rössel]] 08:32, 2 June 2010 (UTC) ::: If I put something in the RC global stylesheet for 'pre', I don't want to name a font that may be platform-specific. Is there a font (say, "Courier" or "Monospace") that works across platforms? Alternately, I could use some free-license webfont, if folks can agree on one. --[[User:Short Circuit|Michael Mol]] 12:18, 2 June 2010 (UTC) :::: I have no idea whether there are such fonts. Windows itself comes with Lucida Console, Courier New and Consolas (as well as a bunch of CJK fonts which are not really meant to be used in Latin-only contexts [at least, judging from the looks of their Latin glyphs]). Linux and similar systems tend to have fonts with quite creative names, such as Mono, Sans or Serif – I have no clue whether that are the actual names of the typefaces or merely aliases for fonts one actually might know.

:::: In any case, you can list a number of typefaces in decreasing order of preference which is pretty common practice. The keyword "monospace" refers to a non-specific (user-defined) monospaced font (which is what's currently used, apparently – either intentionally or just by not redefining `font-family` on `<pre>` – but that runs into the problem with Lucida Console at least with IE on Windows). So you could, theoretically, give a long list of fonts that are known to work and present on most, if not all systems. Downloadable fonts (WOFF, EOT, etc.) may be a last resort option but for a single language probably way overkill. Another possibility would be to tweak J syntax highlighting that numbers in boxes are no longer rendered in boldface. —[[User:Hypftier|Johannes Rössel]] 20:53, 3 June 2010 (UTC)

::::: On that 64 bit vista system, running Chrome, text which is not bolded still looks wrong. For example: [[Compile-time_calculation#J]]. (It looks fine in IE. I did not install firefox.) Anyways, it is not clear that bold is the issue. --[[User:Rdm|Rdm]] 11:55, 4 June 2010 (UTC)

== (Only appeared) Vandalization-like modification to C code ==

Take a look at the history and the C code. It seems it was removed a correct implementation, replaced or "prefixed" with a imagined silly conversation, and then replaced with a code that works on the ASCII representation of (non generic) list, but it is no way useful to flatten a '''real''' and "general" list held in memory; to me that code does not solve the task, since the ASCII representation of a list is not what we usually have when dealing with lists; the previous removed code did. I'll fix it back if no strong motivation for keeping the current silly and simplistic tricky implementation is given. --[[User:ShinTakezou|ShinTakezou]] 10:15, 1 October 2010 (UTC)

: +1 on putting the original code back, but I'm not so sure it was vandalism - maybe an over-enthusiastic mod by someone who hasn't lurked enough? --[[User:Paddy3118|Paddy3118]] 11:11, 1 October 2010 (UTC)

:Actually, if someone were to wrtie a corresponding [[Tree traversal]] routine, in C, that took in the string "[1,[2,[4,7],5],[3,[6,8,9]]]" which is a nested list representation of the example tree, then, ''but only then'', the disputed C routine for list flattening gains merit. --[[User:Paddy3118|Paddy3118]] 13:55, 1 October 2010 (UTC)

::I vote change it back, if it's incorrect. I think it's possible that the editor doesn't understand what a list is. (He may have been going for a "clever" solution; I doubt it was meant as vandalism, else he probably wouldn't have created a user account.) -- [[User:Eriksiers|Erik Siers]] 14:56, 1 October 2010 (UTC)

I have reverted the changes I made. Sorry for the inadvertent breach of protocol. I didn't realize it would cause so much consternation. I assumed most people here would immediately understand. If not, let me plead my case. First, I think you have to admit that my solution yields the correct answer for all well-formed lists so how wrong can it be?

Second, just because one may not be accustomed to seeing a list being represented as a string doesn't mean it is not valid. One can easily implement the entire list API in C using a string as the internal representation, and it will have roughly the same performance as a native lisp list. (If in doubt, see the Tcl code below.)

Third, that "imagined silly conversation" where the professor extols Scheme, ridicules C, and finally says "just strip away all the extra parentheses" is not imagined at all. It is roughly what a professor at a prestigious university once said when flattening a list in Scheme, and it breaks my heart to see so many people so uninformed about C. If you just want to strip out the parentheses why not just do it directly? And, what is more expressive than a language that lets you easily do so?

Granted, to the uninitiated, my solution may seem sophomoric at first, but consider this: Most of the languages with built-in list processing are based on the lambda calculus, but for some reason, it gets lost that regular expressions have just as deep mathematical roots. It seems pretty clear to me that the Unix/C people explicitly chose regular expressions over lambda calculus. For example, they could have passed S-expressions through their pipes, but instead of lists, they chose to pass strings and then use regular expressions to slice and dice. So it stands to reason, that there is probably a very deep equivalence between lists and strings for which most Unix/C people have an intuitive feel. For example, is there any real difference between Lisp's (car lst) and (cadr lst) and Awk's \$1 and \$2? I think another clear example of this is Lisp's (eval) vs. C's lex/yacc, but I'll leave it to the reader fill in those details.

Lastly, in the real world, there is probably no better example of the equivalence between lists and strings than Tcl which is implemented in C and which maintains an equivalence between all lists and strings. For example, the following Tcl code flattens a list simply by treating it as a string. (The Tcl code below works provided the list does not hold strings with embedded braces, but this problem can be fixed with a better regexp.) Note that at all times, the Tcl list is available as a '''real''' and "general" list held in memory as demonstrated by the use of the "llength" function before and after flattening the list, but that doesn't prevent the list from being by treating directly as a string. Also, regarding the point that one needs a tree traversal routine written in C that traverses lists implemented as strings before my solution is correct, one can just link with libtcl to get exactly that.

```
proc flatten lst {
string map {"{" "" "}" ""} \$lst
}

set lst {{1 2 3} {4 5 6}}
puts [llength \$lst]
puts [llength [flatten \$lst]]

```