🚀 go-pugleaf

In article <3880@pasteur.Berkeley.Edu> faustus@ic.Berkeley.EDU (Wayne A. Christopher) writes:

>The way you would add such data types to a language is to build them out
>of the primitives available, which are pointers (in the case of C), or
>arrays (in the case of APL).  Actually adding them as primitives would
>be a very bad idea -- you could never add enough to make everybody happy.

	The plus and minus side of building complex data items into
	the language are:

	+	You don't have to code them (unless you are the language
		designer).
	+	They then form a standard reusable part of the language.
	-	You don't know how they are implemented, so they might
		be inefficient.  At the very least, you don't know the
		cost of individual primitives.
	
	The Icon programming language supplies sets, tables and lists
	as data types, and seems to provide acceptable performance (for
	an interpreter).  If optimum performance is not an issue, it can
	provide a convenient platform to do many kinds of programming
	for which C would be awkward or expensive.

>The sorts of things I use pointers for that I couldn't use arrays for
>are parse trees and graphs (both directed and undirected).  Often there
>is no "higher-level concept" I am trying to express.  Has anybody written
>code to deal with these things in APL?  Is it as ugly as it seems?
	
	I don't exactly see your point here, but there is definately a
	higher-level concept in parsing.  And chances are a language
	with list or tree datatypes would allow you to express that more
	clearly (if less efficiently) than C.   As for APL, well, if you
	are bound and determined, I am sure you could do parsing, but
	why do it when it is poorly suited for the job?

>	Wayne

mark vandewettering