oops cc
----- Forwarded Message ----
From: David Gamey <[email protected]>
To: Andrew Clarke <[email protected]>
Sent: Thu, August 5, 2010 8:54:42 AM
Subject: Re: [Unicon-group] SNOBOL operators - a few questions
Andrew,
As I recall SPITBOL/SNOBOL4 strings were immutable as well. From the
Implementation of SNOBOL and I vividly recall that variable blocks were
identical to string blocks and required an alarming 40 bytes of prefix.
SPITBOL
improved on that but with separate lighter weight string blocks and
optimizations for substrings but they were still immutable as I recall.
In addition to improving the syntax and integrating generators which were huge,
Icon made some different decisions from SNOBOL that were learned from hard
experience. A separate null data type, not auto-converting the null string to
0
for maths, and having runtime error for x + &null shortened many a debugging
session (variable name typos). The create evaluate semantics co-expressions
reversed deferred expressions and solved some problems in that regard (patterns
normally included a heuristic to assume that a deferred expression matched 1
character to prevent death by left recursion. As a result, I'm not yet sure of
the impact of reintroducing deferred expressions.
As far as the assembler from hell syntax - people loved it in spite of that.
It
was a bit of a badge of honour :)
Back in the day of punch cards ... there was a gag for entry level students.
The prep was to write an overly long program and ran it through another that
ensured EVERY line had a label and S/F gotos. If I recall the program labeler
also fluffed up the deck with useless statements to improve the effect. You
kept in your pocket the :(START) and END cards. In front of the students, drop
the 500 card deck in front of the newbies and make sure it gets thoroughly
mixed
up. Act clueless and secretly insert the :(start) and end cards around the
deck. Read it in and presto the program impossibly ran correctly. The looks on
the faces of the newbies was priceless. :)
I liked ?? and &&. I'd have liked it if || could have been changed to work on
patterns as well. I suspect this is because the pre-processor handles it.
Perhaps if we ever get operator overloading.
If patterns are generally available in builds and you have an idea for a
problem/puzzle, you could post it to the Unicon Twiki at tapestry. There's a
link on the Rosetta Code Unicon page if you can't find it. Or search the
archives for the 'state name' problem.
David
________________________________
From: Andrew Clarke <[email protected]>
To: [email protected]
Sent: Wed, August 4, 2010 11:35:32 PM
Subject: Re: [Unicon-group] SNOBOL operators - a few questions
On Thu, 5 Aug 2010 12:57:08 David Gamey wrote:
>
> I came to Icon from SPITBOL/SNOBOL4 and still to this day have what
> I'd characterize as translation moments where I still think in
> SPITBOL patterns.
> Even if the syntax was the assembler from hell
>
;-) I refrained from that obvious stab against SNOBOL. 'twouldn't be
fair or relevant
> There are also a lot of open questions. Pattern Matching in SNOBOL
> was always a language within a language. Putting it back into Unicon
> raises that again. How it integrates with the larger language is
> one of those. Also the ability to mix patterns/scanning/matching is
> an open question. I suspect general integration with scanning (i.e.
> backing up) is less likely than with matching.
>
Generators managed to become beautifully integrated. I expect the
biggest incompatibility is that currently, Icon has immutable strings? I
don't recall how the thesis responded to this, but something's got to
give.
> I'm not sure about the 'klunkiness' of the syntax. Certainly the
> deferred expressions are but they've already been called out as a
> kludge.
>
I'm thinking more the operators like && and .| or -> and $$ not
being particularly symmetrical. Although ?? is a nice -looking choice in
isolation, if SNOBOL's || has to be mapped to .| then maybe && and ??
should be .& and .? just for consistency. Of course I'm just chewing
the fat here.
Also, without really knowing what I'm talking about, perhaps `expr`
could be more consistently lodged behind an operator akin to create
which implies a kind of deferred execution already.
> Basically, you have to use it to gain the understanding you're
> looking for.
>
I think you might be right. One approach would be to get the samples
working for me (hopefully just with cut-n-paste), understand them, and
then attempt to rewrite using my standard Icon style of pattern matching
and collection of results. Perhaps that would highlight the differences.
I think re-reading the thesis is in order now that I've been through the
SNOBOL books. I'm keen to find out what I don't know I'm missing.
Is there scope for a little competition in this regard? Perhaps the fun
factor would get more people trying it, leading to better feedback and
increasing demand.
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Unicon-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/unicon-group
