Re: Introducing PlayDB (The Model, The Language, The DBMS)

From: Mike Preece <michael_at_preece.net>
Date: 3 Nov 2003 18:17:50 -0800
Message-ID: <1b0b566c.0311031817.51e06275_at_posting.google.com>


tonyisyourpal_at_netscape.net (Tony Douglas) wrote in message news:<bcb8c360.0311031031.2f916474_at_posting.google.com>...
> mikepreece <member31023_at_dbforums.com> wrote in message news:<3551763.1067835858_at_dbforums.com>...
> > Originally posted by Christopher Browne
> > > SELF isn't "typeless;" the only language I recall that _claimed_ to be
> > > such was BCPL (predecessor to B and C), and even there, that wasn't
> > > honestly typeless; it was instead pretty "loose" about them.
> Umm & argh. BCPL *was* effectively typeless; it was really monotyped
> (comes to the same thing). Everything was a bit pattern; you could
> offer the compiler some broad hints on what you intended a cell's
> contents to be used for, but there was absolutely nothing to stop you
> using an integer variable as if it were a function, for example. Want
> to do a jump to machine location four ? Easy, just code '4()' and off
> you go. (This was indeed how the global vector worked, and how
> BCPL/Tripos dodged the whole linker issue.)
> > > What could be of _some_ merit would be to have a system that is 'type
> > > agnostic;' that is, you have containers/slots in which you can put any
> > > type. That's sort of what Self does; that's _certainly_
> > > characteristic of the Lisp family. The latter is strongly typed, but
> > > common data structures allow plunking in data of any type, in contrast
> > > with (say) ML.
> A while ago, I defined the semantics of a language which did just
> this; I've still got 30-odd pages of equations around somewhere; it
> also went the whole hog and made types first class values (so you
> could have variables of type type, functions that returned types, etc.
> etc.)
> > > Whether or not this is any good for databases is another
> > > question.
> Almost certainly not, especially where types are first class values
> (imagine a relation with dependent types; not pleasant). I thought
> about this quite a bit before abandoning it.
> > PickBasic treats everything as a string - except that in some contexts
> > strings are treated as numerics. Apart from that it's "type-less".
> Well now this is vey poor news; 85% of programming errors are type
> errors; typelessness doesn't appeal to me one jot with that particular
> (long-standing) statistic around. (This was why one commentator on the
> language mentioned previously stated bluntly he'd rather program in C
> - the biggest insult he could think of at the time.)
>
> - Tony

I don't think you're talking about PickBasic programming errors in that 85% are you? Well you can't be really can you? What would constitute a type error when there are no types? In actual fact, there are type errors in PickBasic though - we get "non-numeric data used where numeric expected" if we try to do something silly and use a string for arithmetic and such. By the way - using a type-less programming language still allows us to handle strictly typed data - we just have to ensure it goes out as the same type as it came in. Oh - that commentator you mentioned - the one with the biggest insult he could think of - has he done a lot of programming with PickBasic?

Have you ever used Icon? It sounds interesting.

Mike. Received on Tue Nov 04 2003 - 03:17:50 CET

Original text of this message