Re: Are Associative Arrays unique to Perl?

ok@cs.rmit.edu.au (Richard A. O'Keefe)
24 Oct 1996 22:37:04 -0400

          From comp.compilers

Related articles
Re: Are Associative Arrays unique to Perl? mjd@plover.com (1996-10-20)
Re: Are Associative Arrays unique to Perl? andy@research.canon.com.au (1996-10-24)
Re: Are Associative Arrays unique to Perl? mzenier@netcom.com (1996-10-24)
Re: Are Associative Arrays unique to Perl? leichter@smarts.com (Jerry Leichter) (1996-10-24)
Re: Are Associative Arrays unique to Perl? ok@cs.rmit.edu.au (1996-10-24)
Re: Are Associative Arrays unique to Perl? hbaker@netcom.com (1996-10-25)
Re: Are Associative Arrays unique to Perl? phr@netcom.com (1996-10-30)
Re: Are Associative Arrays unique to Perl? ian@five-d.com (1996-10-30)
Re: Are Associative Arrays unique to Perl? lhf@csg.uwaterloo.ca (1996-10-30)
Re: Are Associative Arrays unique to Perl? boffi@rachele.stru.polimi.it (giacomo boffi) (1996-10-30)
Re: Are Associative Arrays unique to Perl? sitaram@diac.com (1996-11-03)
[2 later articles]
| List of all articles for this month |

From: ok@cs.rmit.edu.au (Richard A. O'Keefe)
Newsgroups: comp.lang.perl.misc,comp.lang.misc,comp.compilers
Date: 24 Oct 1996 22:37:04 -0400
Organization: Comp Sci, RMIT, Melbourne, Australia
References: <5437ev$30u@shell1.aimnet.com> <545mqn$qul@picasso.op.net> 96-10-099
Keywords: design, history

>[The idea of storing all the strings as unique pointers comes from
>Lisp's atomic symbols, but I hadn't realized that Snobol associative
>arrays were just arrays of pairs.


That is one implementation. There were others: SPITBOL and SITBOL to
name just two. I have no idea how they implement associative arrays.


> Snobol4 was one of the most lopsided
>languages I ever used. It had a fabulous backtracking pattern matching
>system which was powerful enough to write a single pattern that could
>syntax check a Fortran program. But all it would tell you was yes or no --


This is simply not true. Patterns may contain embedded assignments (both
unconditional and conditional) and embedded procedure calls.


Let's see how this might work for parsing simple Fortran variable
declarations: only scalars, significant blanks.


* one or more blanks
blanks1 = SPAN(' ')
* zero or more blanks
blanks0 = blanks1 | NULL
* comma with optional blanks
comma = blanks0 ',' blanks0
* type identifier, saved in type.id
type = ( 'LOGICAL' | 'INTEGER' | 'REAL' | 'COMPLEX'
+ | 'DOUBLE' blanks0 'PRECISION' )
* identifiers
letter = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
digit = '0123456789'
identifier = ANY(letter) (SPAN(letter digit) | NULL)
*
* We're going to have a table mapping identifiers to their types.
* It is only legal to declare an identifier if it doesn't have
* a type yet. This is checked by check.id.
type.of.id = TABLE()
DEFINE('check.id') :around
check.id
type.of.id<this.id> POS(0) RPOS(0) = type.id
+ :F(FRETURN)S(RETURN)
around
checked.identifier = identifier $ this.id *check.id()
*
* At last, the whole statement
*
declaration = blanks0 type $ type.id
+ checked.identifier ARBNO(comma checked.identifier)


>the flow of control was otherwise very primitive. The followon language
>Icon, mentioned a few messages ago, fixed that problem but good. -John]


As for control structures, procedure call is the most important, which
it has, and there is a preprocessor that makes SNOBOL look a lot like Icon.


--
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
[Oh, yuck, you're right. -John]


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.