Jump to content

Talk:SNOBOL

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Jeremybennett (talk | contribs) at 14:28, 30 April 2010 (Paradigms are wrong?: Reference Markov Algorithms). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Snobol and SNOBOL should be merged.


Agreed, but whoever does it has to consider two issues:

Toward that end:

  • i am using Move This Page to move this talk page to Talk:SNOBOL where it is more likely to be seen by the larger number of contributors to SNOBOL
  • i'm adding "see also" links in both directions between SNOBOL and Snobol; they are hopefully temporary.
  • Talk:Snobol should automagically get created as a brand new redirect to Talk:SNOBOL as part of the Move
  • If that doesn't show results in say a month, someone should IMO try to contact some past contributors
  • After say two months, i say just see to the history, then paste Snobol's current content at the foot of the SNOBOL page and let our interested colleagues take care of it as the spirit moves them.

I suggest all this, of course, in the spirit of editing boldly; i'm a new kid on the block, but getting bolder.--Jerzy 10:31, 2003 Oct 13 (UTC)

Regarding the "jocular reference to COBOL"

This is possible, I guess... has anyone verified this with the creators of SNOBOL?

The story I heard (from Polonsky, as I recall, who I knew at Bell Labs), was that the name came from "a snowball's chance in hell," which was said (by whom I don't know) about the prospects for the language succeeding (or, perhaps, being implemented). -- wrote someone on 26 April 2005 without signing the post

I heard this, too, around 1971 or so, I think from Jim Gimpel. Or maybe Polonsky, who I also talked with sometimes.Rochkind (talk) 19:36, 15 March 2010 (UTC)[reply]

My apologies to Rochkind. I was misled by this link in the page history. -- Derek Ross | Talk 20:50, 16 March 2010 (UTC)[reply]

Regarding the original article

It is NOT accurate that languages like AWK and Perl are "more efficient". Notably, well-written programs compiled using the SPITBOL implementation (at least) of the SNOBOL4 programming language are often ten or more times faster in execution than a corresponding Perl program.

Also, while regular-expression-type pattern matching has undoubtedly been made POPULAR by Perl et al, it is a mind-numbingly braindead approach to pattern matching compared to the much richer and more powerful pattern matching capabilites offered by SNOBOL4 and SPITBOL. (If you ever want anyone to take you seriously about this, can the crap and provide examples that demonstrate your way is better. It should be real easy if what you say is actually true.)

Also, Ralph Griswold has stated that the original implementation of the SNOBOL programming language was implemented before the IBM 360, for the IBM 7090. (There is an ACM SNOBOL page from a 1981 ACM talk where Griswold talks about the creation of SNOBOL; ref. http://tennessee.cc.vt.edu/~hopl/Snobol_files/snobol.html )

Gep2 05:19, 28 September 2005 (UTC)[reply]

Someone has put back in a claim that SNOBOL is "more computationally expensive" than regular expressions. Presumably they had not read the above comment. Or if they had, perhaps they would care to explain their grounds for disagreeing. JamesBWatson (talk) 17:31, 25 November 2008 (UTC)[reply]

First Implementation

in the article is credited to the 360, but one of the references cited (http://www.snobol4.org/history.html) has the first implementation on the 7090.

That seems like good enough reason to change it, so I will... Dpbsmith (talk) 16:40, 20 December 2005 (UTC)[reply]
The first implementation of SNOBOL was on the IBM 7090 in 1962. However the first implementation of SNOBOL4 (which is the language you are thinking of when you say SNOBOL) was started on the IBM 7094 in early 1966 but was abandoned in mid 1966. That was because development was switched to the IBM 360 at that time and the first prototype was completed on that machine in mid 1967. -- Derek Ross | Talk 04:37, 10 March 2010 (UTC)[reply]

Added a link to Icon, which is a descendant language, Ranvaig 20:40, 31 December 2005 (UTC)[reply]

CleanUp Template

I am sure that this article could be improved—and if I can find my printout of the manual (DEC 20, SPITBOL or possibly Macro SPITBOL) and my copy of Susan Hockey’s book, and then switch my mind back by a couple of decades, I might even be able to contribute to that. (Sadly, I didn’t have the foresight to steal the computer centre’s copy of Griswold et al, which I am sure has not been used since. It struck me as a fine book.) In the meantime, however, I notice that whoever posted the template message failed to provide the indicated rationale on this talk page. That seems to me to be verging upon spam and I propose therefore to remove it. Any objections?

By the way, the key thing that seems to me to be missing in regexp, as opposed to SNOBOL, is not so much power as human-readability. Ian Spackman 02:34, 16 February 2006 (UTC)[reply]

According to the SNOBOL wiki there is rather more to SNOBOL pattern matching. Not least, the ability to create pattern matching "functions" which can be used within new patterns. --24.205.91.162 18:58, 19 October 2006 (UTC)[reply]

"Hello World" Example

I believe the "END" statement is optional: the interpreter assumes one if none is present. I'm certain (or as certain as I can be since I haven't used SNOBOL in many years) that this was true of the implementation I used (on a CDC 6600). I believe Griswold, Poage, and Polonsky's book specified this behavior, but I no longer have a copy, so I can't very this.

—The preceding unsigned comment was added by Grosbach (talkcontribs) 19:05, 28 March 2007 (UTC2)

Spelling of Polonsky's Name

See, for example: http://portal.acm.org/citation.cfm?id=808393&coll=portal&dl=ACM —The preceding unsigned comment was added by Grosbach (talkcontribs) 19:15, 28 March 2007 (UTC2)

Examples?

This page could really do with some examples ... Richard W.M. Jones 09:10, 15 July 2007 (UTC)[reply]

Good point. Maybe I'll find time to write some. JamesBWatson (talk) 17:29, 7 December 2008 (UTC)[reply]

Removal of statement about power of Snobol pattern matching

Chbarts has removed the sentence "However, the pattern matching capabilities of SNOBOL are significantly more powerful than those of regular expressions", giving in his edit summary "Removed uncited, undemonstrated statement". The statement is indubitably true, and I shall endeavour to find a citation to justify it.
I would have preferred it had Chbarts given warning, taking note of the following from Wikipedia's Verifiability policy:
Any material lacking a reliable source may be removed, but editors might object if you remove material without giving them sufficient time to provide references. If you want to request a source for an unsourced statement, consider tagging a sentence by adding the {{fact}} template, a section with {{unreferencedsection}}, or the article with {{refimprove}} or {{unreferenced}}. Alternatively, you may leave a note on the talk page requesting a source, or you may move the material to the talk page.
I should also be interested if Chbarts would like to give his reason for choosing to remove it. Editors frequently use lack of a citation as reason for removing text, but it is never the complete reason, as there are invariably many other uncited statements which are left alone. The whole of this article would have gone had that been the sole reason. JamesBWatson (talk) 17:47, 7 December 2008 (UTC)[reply]

It's a statement just redolent of boosterism, like claiming the language is 'easy to learn', or 'more intuitive than...' some other language. If it isn't cited and attributed to a specific source, it's a violation of NPOV. From my view, it's the only part of the article that violates NPOV, so it was the only part I was moved to remove. --chbarts (talk) 23:34, 7 December 2008 (UTC)[reply]


Thank you for explaining your reason. It is always helpful to give clear reasons for deleting other editors' work.
Until I read this I had never heard of "boosterism"; I have now looked it up. Evidently it is an American colloquial word referring to making vague statements in favour of some entity one has a personal attachment to, such as one's home town. I have no personal attachment to Snobol, and do not use it.
I can see that the statement can be read as a subjective opinion; however, I think there is a sense in which it is objectively true: (a) there are things which can be done with Snobol pattern matching but not with regular expressions, and (b) there are things which can be done with either, but much more concisely and simply with Snobol. I have certainly seen examples of this, and I shall try to find suitable citations when I find time.
JamesBWatson (talk) 15:08, 9 December 2008 (UTC)[reply]

It's hard to talk knowledgeably about SNOBOL without it sounding like "boosterism" but that's because these things are true, and marvelous. The language is syntactically very simple, regular and orthogonal, making it very very easy to learn. The almost total lack of reserved words means that as a rule you can safely ignore the parts of the language that you don't know yet when writing programs. As far as needing "citations", that's like the old saying about how an expert is "someone that comes from somewhere else." When a person who knows the subject well writes HERE, that ought to be treated with the same respect as the same expert writing somewhere else.

As for SNOBOL being computationally expensive, that used to be true in days where computers were a great deal slower than they are today, and when compared to relatively primitive languages (such as assembler) which add little or no overhead of their own. Certainly the SPITBOL implementation is EXCEEDINGLY fast, and even the CSNOBOL implementation is very much more than fast enough on modern hardware that it shouldn't dissuade its use, especially when compared to other languages which often today are much slower (such as Perl).

It is true that it is relatively easy in SNOBOL, especially when writing rather careless patterns, that you can easily create patterns which generate a whole lot more work for the processor than they probably need to do. Programming efficiency is something that is important in ANY programming language, if you want the program to run as fast as possible. The fact that careless people can easily write patterns which perform poorly is due more to their lack of expertise than it is because of inherent problems in the language.

That said, for many types of programs (and specific places within programs) the tradeoff between programming time and run time is something that one can use to their advantage to reduce the total cost of a program.

Personally, I object strenuously to the introduction to the article where it sounds like Perl and AWK are more modern and generally preferable to SNOBOL, which is only really widely believed because the proponents of languages like Perl are generally ignorant of SNOBOL/SPITBOL and its advantages. If we're going to have snarky comments about SNOBOL in this article, then we SNOBOL people ought to be able to go and put snarky things in the Perl article about how Perl and other more widely used programming languages are inherently crippled or hobbled by being based on braindead regular expressions. Fair is fair.  :-) Gep2 (talk) 02:35, 26 December 2008 (UTC)[reply]

Several points here.
First of all, about citations vs. experts, Wikipedia has learned through painful experience that it is very difficult to deal with experts writing on their subjects without sources, for a variety of reasons. Not all experts in a given field agree, whereas Wikipedia is committed to fair representation of all reputable positions (WP:NPOV). Experts (like anyone else) often have their hobbyhorses, and find it difficult to separate their pet topics from what is generally accepted in their field. Allowing expert individual opinion also makes it procedurally difficult to separate cranks from serious experts. And of course anyone can pose as an expert. All in all, Wikipedia hasn't figured out how to work well with experts, which is a problem, but that's the current state of things.
About "power", I don't know if Snobol4 patterns are theoretically more powerful than Perl's regular expressions (which of course are much more powerful than true regular expressions), since Perl now has the evaluate-during-pattern-match feature/hack ?{}. After all, even two-counter machines are Turing-equivalent. And Perl's patterns no doubt compile into far better code in many special cases, so they may be more powerful in that sense.
However, Snobol4 has a clean, general backtracking pattern matcher while Perl has a baroque system built up from special cases. That is important.
The problem here is using general terms like "powerful", which aren't specific enough to be useful to the reader. Talk about Snobol4's generality, about pattern functions, and all that instead of just saying Snobol is more powerful than Perl.
As for the speed issue, the argumentation above doesn't make much sense: "a rising tide floats all boats". Yes, no doubt Snobol is practical today for problems for which it was impractical 20 years ago simply because machines are so much faster. But that is true of any other system. The relative speed still matters. If I can solve a given problem in time x in C and in time 100x in Snobol, it doesn't much matter if x = 1 mS, but it may matter a lot if x = 10 seconds. The real problem comes, of course, if the order of complexity is higher in one system than another. Snobol arguably makes it very easy to write exponential-complexity backtracking algorithms. But then, you can also write exponential-complexity backtracking algorithms in Perl.
Again, I think it is a waste of time to argue that Snobol is faster or slower than Perl. Be more specific about its properties, including its strengths (and weaknesses), and these silly arguments about whether Snobol is more powerful or faster than Perl will become completely irrelevant. --macrakis (talk) 03:36, 26 December 2008 (UTC)[reply]
I boldly edited Gep2's recent edit to add a NPOV. If there are going to be definitive statements about the relative power of one approach over another, there needs to be citations to primary sources. There probably need to be citations to many of the statements in the overview of SNOBOL that is being edited, such as the reason for the decline of SNOBOL's popularity in Universities, but I let it stand as I'm not bold enough to rip the whole thing out (is that appropriate? or should one of those statements about need for Citations be added to the top?) JordanHenderson (talk) 19:32, 26 December 2008 (UTC)[reply]

I'm checking back in because I got this little ball rolling but I was gone over the holidays. Personally, I think macrakis has it exactly right: We need to uphold NPOV and that is only done via citations to reputable sources. This article is mostly fairly good (some more code snippets might help) but that statement is a blemish as long as it isn't explicitly coming from somewhere cited. Secondly, it's either difficult or meaningless to talk about 'power' in this sense. Power needs to be a mathematical concept or it is just pure boosterism. And, finally, I do want to discuss this. I just think non-NPOV statements should be removed first, and only added in when consensus has been reached on how to make them NPOV. --chbarts (talk) 01:40, 29 December 2008 (UTC)[reply]

I see what Chbarts is getting at. However, "I just think non-NPOV statements should be removed first, and only added in when consensus has been reached on how to make them NPOV" is inconsistent with Wikipedia's Verifiability policy (quoted from above). Then we have "Power needs to be a mathematical concept". Why? If I can see that I can do X by using tool A but not by using tool B then, for that purpose, tool A is more powerful than tool B: I do not need mathematics to show me that. JamesBWatson (talk) 13:06, 31 December 2008 (UTC)[reply]

Power needs to be a mathematical concept because that is the only way we can all agree on what is and is not powerful. For example, I can say "Assembly language is the most powerful language" and you can say "SNOBOL is the most powerful language" and we'd both be right in ways that largely have nothing to do with each other: Assembly language gives you full control over the hardware (possibly limited by an OS or other mechanism), whereas SNOBOL gives you a great amount of control over all strings your program handles. By restricting our definition of the word 'power' to what's proven in formal language theory we can avoid talking past each other. By the same token, without a cite providing some concept of what we mean by 'power' in this article, the statement is simply meaningless; it's like saying SNOBOL is redder than Perl. --chbarts (talk) 08:40, 8 January 2009 (UTC)[reply]
Formal language theory is great, but has its limits. From the point of view of formal language theory, a two-counter machine is as powerful as a Turing machine, which is as powerful as any real programming language (assuming they're running on infinite machines...). But I'd hate to have to write any non-trivial piece of code on a raw two-counter machine. (You would of course use a tower of abstractions on top of it, which gets back to the question of the expressiveness of the abstractions.)
So, I don't think the notion of "power" as some magic single metric is useful here.
It is more useful to talk more specifically about what makes Snobol's patterns expressive or useful or concise or efficient (or not) as compared to true regular expressions, Perl's extended regular expressions, etc.
Show, don't tell. --macrakis (talk) 15:25, 8 January 2009 (UTC)[reply]

I previously wrote "I see what Chbarts is getting at", and, although I did not entirely agree with Chbarts, I thought that there was a good deal of sense in what he said. However, I feel quite differently about his latest contribution.

Consider "Power needs to be a mathematical concept because that is the only way we can all agree on what is and is not powerful". Firstly, the notion that a concept is of no use unless it is universally agreed upon is nonsense. Secondly using a mathematical concept does not by any means guarantee that we will all agree. Chbarts can come up with a mathematical concept based on formal language theory, but this does not force us all to agree that that concept is the appropriate one to use, as Macrakis's comments above illustrate.

Consider "For example, I can say 'Assembly language is the most powerful language' and you can say 'SNOBOL is the most powerful language' and we'd both be right in ways that largely have nothing to do with each other". In that sentence Chbarts has quite rightly and quite clearly asserted that there are different concepts of power, which can have applicability in different contexts. Yet he appears to think that this is an argument in favour of the exact opposite: that there is only one concept of power, namely that defined in formal language theory.

Consider "By restricting our definition of the word 'power' to what's proven in formal language theory ...". Chbarts does not seem to see that doing this would deny anyone the right to refer to other concepts of power. There are, as Chbarts himself has indicated, several concepts of power, and there is no reason why we should not be able to use any one of them which is appropriate in a particular situation.

Consider "By the same token, without a cite providing some concept of what we mean by 'power' in this article, the statement is simply meaningless; it's like saying SNOBOL is redder than Perl". No it isn't, for at least two reasons. First of all, saying that a programming language is "red" has no meaning that I know of. Saying that a language is more powerful than another certainly has meaning; it is true that it has a cloud of meaning, and that in a particular context it may be necessary to restrict the meaning for clarity, but that is a long way short of being totally meaningless like saying that a language is "red". Secondly, the notion that a word is meaningless unless we can define it is what Geach called "the Socratic fallacy"; again, clarification may be useful, but that is not the same as saying that meaning exists only in defined words. In any case, even if we grant Chbarts his contention here, we are only granting that terms must be defined: this is nothing like granting his assertion that terms have to be defined as mathematical concepts.

Certainly I agree with Chbarts that it would be more helpful to quote examples of specifically what can be done more easily in SNOBOL than in Perl than simply to state that "SNOBOL is more powerful than Perl" without explanation or justification. However, by trying to defend the contention that only one meaning of "power" is permissible, Chbarts has moved from a reasonable, albeit debatable, position, to a quite untenable one, it seems to me. JamesBWatson (talk) 13:37, 14 January 2009 (UTC)[reply]


I just found a reference: "SNOBOL4, Features: Pattern matching based upon BNF grammars" ( Pratt, T.W. Zelkowitz, M.V. Programming Languages: Design and Implementation. 3rd edition Prentice Hall, Englewood Cliffs, New Jersey 1996, page 255). BNF Grammars are equivalent to Context Free Grammars, that are more powerful than regular expressions.

Also, there is this discussion in (http://tech.groups.yahoo.com/group/snobol/message/656) which points to the paper that "ends" this discussion. SNOBOL pattern language ARE more powerful than regular expressions.


QUOTING-----

This whole discussion has been fun. It got me to looking back through some of my old paper files on SNOBOL. One of the most interesting was "A Theory of Discrete Patterns and Their Implementation in SNOBOL4" by J. F. Gimpel, CACM, V16, N2, February 1973. I'm not sure it has any relevancy to the Wikipedia discussion, but it is probably the most detailed attempt at a formal description of SNOBOL pattern matching.

The paper starts by claiming 5 properties for SNOBOL4 pattern matching:

 1.  The patterns of SNOBOL4 not only subsume the BNF grammars, they can
      also specify (with the help of defined functions) any decidable language.
 2.  The patterns of SNOBOL4 are not limited to sets of strings (as in
      formal languages), but can represent a "selection process", which,
      while more general, nonetheless yields to rigorous formulation.
 3.  The pattern-building process in SNOBOL4 eliminates the "tops" of a
      top-down specification, thereby rendering a simpler implementation
      scheme than the classic top-down method of Floyd [5}.
 4.  The pattern-matching process breaks most left-recursive loops.
 5.  The scanner has built-in heuristics that enable it to detect at an early
      stage that a pattern will fail.

Near the end he states that the search algorithm "...resembles somewhat the search algorithm of Thompson [14]; his algorithm, however, is limited to regular expressions".

I'm not claiming that this is an argument against the Wikipedia language newbies, but it is a reference and perhaps food for thought.

Jim Mehl


END QUOTING —Preceding unsigned comment added by Xexeo (talkcontribs) 00:47, 27 January 2009 (UTC)[reply]

The paper is referring to regular expressions sensu strictu. But most modern so-called regular expressions (as found in Perl etc.) can recognize non-regular and in fact even non-context-free languages thanks to back-references, e.g. '(a*)b*\1'. And apparently Perl patterns (like Snobol patterns) can call arbitrary code now, so maybe they are theoretically equivalent. Still, Snobol patterns are far cleaner and more expressive as far as I'm concerned. --macrakis (talk) 01:42, 27 January 2009 (UTC)[reply]

Examples

SNOBOL is a strongly-typed language, in that the system always knows what data type a variable contains, although you can change any variable's type at any time by simpy assigning a value of a different data type to it. The first-class data types include:

  INTEGER
  REAL
  STRING
  PATTERN
  CODE
  ARRAY
  TABLE
  EXPRESSION
  USER-DEFINED DATATYPE

Explicit declaration of variables is not required. All undefined variables default to the value of a null string.

An asterisk in column 1 of a line indicates that the rest of the line is a comment.

All statements in SNOBOL syntactically consist of five parts, although all five parts are optional. The basic syntax is:

label subject pattern = object  :(goto)

The special label "end" signifies the end of the program.

Operations in SNOBOL generally SUCCEED, and produce a value (which might be the null string) or FAIL and produce NO value at all). Success and Failure are the basis of all (explicit) conditional transfers of control.

Gotos can be unconditional:  :(label)

 or based on success:                         :s(label)
 or based on failure:                         :f(label)
 or can specify for both:                     :s(label1)f(label2)

The evaluation of a SNOBOL4 statement generally proceeds as follows:

 1.  The subject is evaluated.
 2.  If a pattern is present, it is evaluated.
 3.  The evaluated pattern is matched against the subject.
 4.  The object is evaluated.
 5.  The value of the object (if there is no pattern) is assigned to the subject, or (if there is a pattern) replaces the portion of the subject that was matched by the pattern.
 6.  If "failure" occurs at any point in the above process, and in the absence of successful alternatives, execution of the statement terminates and goes to the appropriate unconditional or "failure" goto (if any) or else to the next statement in sequence.  If the statement succeeds completely, execution continues with the unconditional or "success" goto, or with the next statement in sequence.

The statement:

   x = 1

simply sets the type of X to INTEGER and assigns it a value of 1.

A trivial pattern match would be (if the initial value of STR is "ABCDEF"):

   STR  "CD" = "WXYZ"

That statement would succeed, and the value of STR would now be "ABWXYZEF".

Input and output in SNOBOL work by associating variables with files, and subsequently the variable works like a "magic can". Whenever something is stored into an output-associated variable, it is ALSO written to the associated output file. Whenever the value of an input-associated variable is accessed, the next record of the associated input file is read and returned as the new value of that variable (or FAILURE, and NO value returned. if the input file is at EOF).

The variable INPUT by default is associated with the standard input file. OUTPUT by default is associated with the standard output file. TERMINAL by default is output-associated with the screen, and input-associated with the keyboard.

Therefore, a simple program which copies standard input to standard output is simply:

somelabel output = input :s(somelabel) end

The classical "Hello, world" program is simply:

      terminal = "Hello, world!"

end

It is obviously beyond the scope of this section to describe the entire language, but hopefully this gives at least a brief look. Gep2 (talk) 03:35, 26 December 2008 (UTC)[reply]

The story of the naming!

Dave Farber read this entry, was somewhat annoyed by it and wrote up the story of now SNOBOL was named. w00t :-) - David Gerard (talk) 14:42, 26 December 2008 (UTC)[reply]

Of course this is more useful to people who might want to correct the page by providing a link to David's history of SNOBOL. --BenFranske (talk) 16:31, 26 December 2008 (UTC)[reply]
Yes, I didn't post it on this talk page until I'd edited the article ;-) - David Gerard (talk) 16:47, 26 December 2008 (UTC)[reply]

Paradigms are wrong?

Can anyone support that SNOBOL is functional, object-oriented and logic????

I am actually preparing a course on Programming Languages and I am finding difficulties to classify SNOBOL4. It is a pattern matching language based upon BNF Grammars. —Preceding unsigned comment added by 201.19.27.51 (talk) 00:31, 27 January 2009 (UTC)[reply]

The anon has a point about "functional, object-oriented and logic" in the article and in fact I deleted that passage. --macrakis (talk) 18:09, 27 January 2009 (UTC)[reply]

Snobol has many good properties, and its very general backtracking pattern-matching mechanism is not found in most other languages. So it is useful to compare that mechanism with that of Prolog, which has similarities. But let's not go overboard with that. As for its being easy to use Snobol as either a functional or imperative language, that is true for many languages, including C. --macrakis (talk) 03:16, 4 February 2009 (UTC)[reply]

I agree that some of the editors of this article have gone somewhat overboard. Certainly I feel the claim that SNOBOL can be used as an object oriented language was overstated. I am not sure how far I could justify implying that SNOBOL is easier to use as either a functional or imperative language than other languages, so I will let that drop unless someone else can justify it. However, it seems to me that once you have accepted the statement that SNOBOL's backtracking algorithm is similar to Prolog's it is difficult to see the objection to stating that this "makes it easier to use SNOBOL as a logic programming language than is the case for most languages". I am therefore inclined to restore this statement. However, I shall wait a while to see whether anyone can justify its removal, as whenever there is controversy I do not like the style of editing which consists of barging in and undoing everything you disagree with, without giving others a chance to comment. JamesBWatson (talk) 14:29, 4 February 2009 (UTC)[reply]

Functional programming is a very broad term. In a broad sense, any language that supports passing functions as arguments (even if they are passed using their name) can be used for functional programming. This is true of most languages these days. Even when SNOBOL was designed, many languages, including not just Lisp but also Fortran, PL/I, Algol, etc. supported some form of functional arguments -- though typically they were not type-safe etc. When languages started to have stricter type systems, treating functions correctly became much harder. Thus for example Ada does not have full functional arguments, but only a static version (generics). Stricter definitions of functional programming would require first-class function objects (you pass the function itself and not its name) and probably lexical scoping, though that would rule out the 1960's and 1970's versions of Lisp (which had dynamic scoping and often treated functions just as list structures). And if you really want to do it right, you probably need ML-style polymorphism. Where does SNOBOL fit into all this? I believe it fits into the first category, so saying you can do functional programming in it is pretty much vacuous.
Imperative programming -- yes, of course you can do imperative programming in SNOBOL, as you can in almost every language (except purely functional etc.).
Logic programming -- though logic programming a la Prolog is done using backtracking, and SNOBOL has some of the same mechanisms (automatic backtracking, cut = FAIL), there are also many differences. SNOBOL only does backtracking pattern-matching on strings (not general data structures), does not do unification (though you can simulate the black-box effect using assignments during pattern-matching), etc. Are there any reliable sources demonstrating the use of SNOBOL for logic programming? Is there a non-trivial user community using SNOBOL for logic programming? I doubt it. --macrakis (talk) 15:17, 4 February 2009 (UTC)[reply]
One possibly relevant paper is Jared L. Darlington, "Search direction by goal failure in goal-oriented programming", ACM Transactions on Programming Languages and Systems 12:2:224-252 (April 1990), which implements a non-procedural language using SNOBOL, but it still seems like a stretch.... --macrakis (talk) 15:46, 4 February 2009 (UTC)[reply]
As the person who originally contributed the statements about the various programming paradigms that SNOBOL4 can support, I thought I should comment, even though it is a year later. Particularly on the Functional Programming side. For me an FP language has to allow the handling of functions as first-class objects and SNOBOL4 does allow this via judicious use of its DEFINE() and CODE() functions which allow one to define and redefine functions (including anonymous ones) dynamically using strings instead of linked lists. This puts it far beyond the function-passing category of programming languages such as FORTRAN or Algol and well into LISP territory. One could certainly write a continuation-passing function in SNOBOL without too much difficulty whereas doing the same in Pascal might present some problems. Likewise polymorphism is straightforward to handle in SNOBOL since the user definable data type is an accessible property of each variable.
As for Logic Programming techniques, LP in Prolog is obviously different from LP in SNOBOL4 -- just as pattern matching in AWK is obviously different from pattern matching in SNOBOL4 -- but since SNOBOL4 pattern matching can tell whether an arbitrary string matches an arbitrary BNF grammar definition, it has equivalent power to Prolog. And strings are just as general as linked lists when used to represent data structures, so saying that "SNOBOL only does backtracking pattern-matching on strings (not general data structures)" is like saying "Prolog only does backtracking pattern-matching on predicates (not general data structures)": true but not actually limiting..
In any case I'm not too worried about losing the statements. I can support the statements by providing program examples but the statements were made at a time when Wikipedia was a much simpler place than it is today and I agree that they need citation by today's standards. I'm actually quite surprised that they survived unchallenged for seven years. -- Derek Ross | Talk 07:01, 15 February 2010 (UTC)[reply]
One more comment on "only does backtracking pattern-matching on strings (not general data structures)". Not only is it theoretically possible to represent any data structure as a string, but in practice SNOBOL makes this more manageable than other languages I have experience of. I have known highly effective use of SNOBOL pattern matching for all data structures that would not normally not be thought of as strings. JamesBWatson (talk) 17:33, 28 February 2010 (UTC)[reply]
Of course it is possible to represent any data structure as a string, and of course it is possible to use pattern-matching on these strings. That doesn't mean that Snobol supports pattern-matching on arbitrary data types. If that were the definition of 'support', then all programming languages support all paradigms, since they are Turing equivalent. Along the same lines, arbitary-precision numbers (e.g.) can be represented as strings (or as arrays or as data structures), and manipulated effectively in Snobol. But even so, we don't conclude that Snobol supports arbitrary-precision arithmetic. --macrakis (talk) 18:03, 28 February 2010 (UTC)[reply]
Understood, Mackrakis. I think it's really a question of how easy a language makes it to use a particular programming paradigm though. And SNOBOL4 does make it easy to use an LP approach with the built-in facilities whereas if I were to try using an LP approach with C or Pascal, it would be much more difficult. -- Derek Ross | Talk 16:13, 11 March 2010 (UTC)[reply]


Macrakis's comment completely ignores the words "highly effective" in my comment about use of SNOBOL pattern matching for data structures that would not normally not be thought of as strings. Use of a Turing machine is theoretically possible but not effective. The point is not that it can be done in SNOBOL but that it can be done effectively in SNOBOL. JamesBWatson (talk) 16:53, 11 March 2010 (UTC)[reply]
Surely the paradigm should also mention Markov algorithms? I always understood this was the underlying paradigm. Jeremybennett (talk) 14:28, 30 April 2010 (UTC)[reply]

Neutrality

Maybe its just me, but the section comparing it to regex seems a bit one-sided. I don't know that much about SNOBOL, so perhaps it realy isn't, but thought i'd mention. Bawolff (talk) 20:43, 18 September 2009 (UTC)[reply]

I have rewritten it: is it any better? JamesBWatson (talk) 13:47, 25 September 2009 (UTC)[reply]