Hi
For what types of projects should one choose Lisp and for what types
of projects should one choose *ML? Is there a set of clear criteria?
Are these groups of languages basically two different tools for two
different jobs, or are they essentially competing for the same
"ecological niches", such as for example machine learning, expert
systems, compilers, etc.?
Best Regards
"Alex Braun" <······@cyberspace.org> wrote in message ·································@posting.google.com...
> Hi
>
> For what types of projects should one choose Lisp and for what types
> of projects should one choose *ML? Is there a set of clear criteria?
It depends.
> Are these groups of languages basically two different tools for two
> different jobs, or are they essentially competing for the same
> "ecological niches", such as for example machine learning, expert
> systems, compilers, etc.?
How do languages `compete'?
"Joe Marshall" <·············@attbi.com> wrote in message news:<·····················@typhoon.ne.ipsvc.net>...
> "Alex Braun" <······@cyberspace.org> wrote in message ·································@posting.google.com...
> > Hi
> >
> > For what types of projects should one choose Lisp and for what types
> > of projects should one choose *ML? Is there a set of clear criteria?
>
> It depends.
That was exactly my question: what does it depend on?
> > Are these groups of languages basically two different tools for two
> > different jobs, or are they essentially competing for the same
> > "ecological niches", such as for example machine learning, expert
> > systems, compilers, etc.?
>
> How do languages `compete'?
I thought this was pretty obvious: they compete for the affections of
project managers, programmers, scientists, etc.
BTW if you are a bot, you aren't passing the Turing test well.
"Alex Braun" <······@cyberspace.org> wrote in message ·································@posting.google.com...
>
> BTW if you are a bot, you aren't passing the Turing test well.
However, if I am not a bot, I'm doing a great job at
passing the *inverse* Turing test.
* Alex Braun
| For what types of projects should one choose Lisp and for what types of
| projects should one choose *ML? Is there a set of clear criteria?
No. There never are. All criteria are fuzzy and useless.
Which is the best car? How do you choose? Here's how this works: You
look at a few cars, far from all, then feel good about a few models.
Then you construct an elaborate rationalization for why these are the
good choices and all other cars are useless pieces of metal and plastic,
gas-guzzling deamon machines, etc. Then you tell your friend(s) and
colleague(s) and spouse(s) and kid(s) and cat(s) why these are the good
choices, mainly to convince yourself. Then perhaps you look at one or
two or three completely irrelevant attributes of the models you think are
good, and wind up with a single choice -- this is the car you want! Then
you make up an even more elaborate rationalization for your choice and
you memorize a lot of technical details about your car, but know nothing
about any other car (except possibly your last, if you still remember).
That you only know your chosen car is quite irrelevant, since any friend
or colleague or spouse or kid or cat who has done the same thing for
another car will just tell you _their_ memorized technical details and
you can play a very manly game of "compare random meaningless numbers" in
which every single participant wins, knowing with ever more certainty
that his chosen car was the best possible choice all along. You might as
well just make up reasonable numbers and lie. Nobody will know or care.
Then you are a happy car owner and you really enjoy the greatest car ever
and you polish it and care for it and give it a pretty name that you do
not disclose to your spouse. However, if this should in _any_ way fail
and the self-convincing magic breaks down in a fit of objectivity and
rationality, you try very hard to glorify the miserable piece of metal
and plastic so some hapless second-hand victim will be utterly convinced
not only that _he_ is the lucky one who gets your used car, but that he
should finance your next car, too, in fact that he is _much_ better off
with your used car than the new car you want, considering how much you
cared for it and nobody has cared for a new car, yet, have they? No.
So the criterion is this: That you are happy with your choice.
The catch is that absolutely every car that has ever been sold _is_ the
best car ever, but _was_ a piece of junk. Every single owner of a car
will argue exceptionally well for his current car, completely oblivious
to any facts to the contrary, and will present strong qualitative and
scientific evidence to support his case, yet without any trace of effort
will change his mind when it has been sold, peaking in his evaluation
just prior to closing the deal. If it was the right choice to buy, it
was certaily the right time to sell. Mistakes do not happen when you buy
or sell cars -- it is too damn essential to your life to make any sort of
mistake with such an acquisition, so you just don't. It is that simple.
Of course, none of this is emotional. Buying a car because you feel good
about it is hopelessly immature and ridiculous. Nobody does that. Well,
maybe your stupid neighbor who clearly cannot afford showing off like
that, but at least nobody _normal_. Being able to defend your choice
rationally is probably even more important than actually buying the car.
| Are these groups of languages basically two different tools for two
| different jobs, or are they essentially competing for the same
| "ecological niches", such as for example machine learning, expert
| systems, compilers, etc.?
No to both alternatives. That you can drive your car to work is the
single most irrelevant consideration that went into your choice.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Eric, so you wrote this 3Kb piece only to state the obvious: "you had
made the right choice if you were happy with it later". Are you
retarded? Having other mental problems?
> * Alex Braun
> | For what types of projects should one choose Lisp and for what types of
> | projects should one choose *ML? Is there a set of clear criteria?
>
> No. There never are. All criteria are fuzzy and useless.
>
> Which is the best car? How do you choose? Here's how this works: You
> look at a few cars, far from all, then feel good about a few models.
> Then you construct an elaborate rationalization for why these are the
> good choices and all other cars are useless pieces of metal and plastic,
> gas-guzzling deamon machines, etc. Then you tell your friend(s) and
> colleague(s) and spouse(s) and kid(s) and cat(s) why these are the good
> choices, mainly to convince yourself. Then perhaps you look at one or
> two or three completely irrelevant attributes of the models you think are
> good, and wind up with a single choice -- this is the car you want! Then
> you make up an even more elaborate rationalization for your choice and
> you memorize a lot of technical details about your car, but know nothing
> about any other car (except possibly your last, if you still remember).
> That you only know your chosen car is quite irrelevant, since any friend
> or colleague or spouse or kid or cat who has done the same thing for
> another car will just tell you _their_ memorized technical details and
> you can play a very manly game of "compare random meaningless numbers" in
> which every single participant wins, knowing with ever more certainty
> that his chosen car was the best possible choice all along. You might as
> well just make up reasonable numbers and lie. Nobody will know or care.
> Then you are a happy car owner and you really enjoy the greatest car ever
> and you polish it and care for it and give it a pretty name that you do
> not disclose to your spouse. However, if this should in _any_ way fail
> and the self-convincing magic breaks down in a fit of objectivity and
> rationality, you try very hard to glorify the miserable piece of metal
> and plastic so some hapless second-hand victim will be utterly convinced
> not only that _he_ is the lucky one who gets your used car, but that he
> should finance your next car, too, in fact that he is _much_ better off
> with your used car than the new car you want, considering how much you
> cared for it and nobody has cared for a new car, yet, have they? No.
>
> So the criterion is this: That you are happy with your choice.
>
> The catch is that absolutely every car that has ever been sold _is_ the
> best car ever, but _was_ a piece of junk. Every single owner of a car
> will argue exceptionally well for his current car, completely oblivious
> to any facts to the contrary, and will present strong qualitative and
> scientific evidence to support his case, yet without any trace of effort
> will change his mind when it has been sold, peaking in his evaluation
> just prior to closing the deal. If it was the right choice to buy, it
> was certaily the right time to sell. Mistakes do not happen when you buy
> or sell cars -- it is too damn essential to your life to make any sort of
> mistake with such an acquisition, so you just don't. It is that simple.
>
> Of course, none of this is emotional. Buying a car because you feel good
> about it is hopelessly immature and ridiculous. Nobody does that. Well,
> maybe your stupid neighbor who clearly cannot afford showing off like
> that, but at least nobody _normal_. Being able to defend your choice
> rationally is probably even more important than actually buying the car.
>
> | Are these groups of languages basically two different tools for two
> | different jobs, or are they essentially competing for the same
> | "ecological niches", such as for example machine learning, expert
> | systems, compilers, etc.?
>
> No to both alternatives. That you can drive your car to work is the
> single most irrelevant consideration that went into your choice.
Alex Braun <······@cyberspace.org> wrote:
: Eric, so you wrote this 3Kb piece only to state the obvious: "you had
: made the right choice if you were happy with it later". Are you
: retarded? Having other mental problems?
My own working theory is 'Eric types very fast'. Another theory might be
'Eric states the obvious after laying out a detailed metaphor containing
several factors and scene depictions, thus detailing the obvious', but you
could always rebut with a 3kb forward and a 3 line rebuttal.
Either way, it's good Usenet.
* Todd Gillespie <·····@math.utexas.edu>
| My own working theory is 'Eric types very fast'. Another theory might be
| 'Eric states the obvious after laying out a detailed metaphor containing
| several factors and scene depictions, thus detailing the obvious', but you
| could always rebut with a 3kb forward and a 3 line rebuttal.
| Either way, it's good Usenet.
My theory is that people need to look less at who writes and more at what
they read. Perhaps if you had been able to read something without a
truckload of prejudice and expectation, you, too, would find it humorous
at the cost of silly and meaningless requests that betray an utter lack
of understanding of the process of choice. Lots of academics have so
little contact with the real world that they actually believe that there
could be such a thing as (universally applicable) "clear criteria" for
any choice. I mean, you can only laugh at that ridiculous break with
reality -- it is too goddamn sad to take any more seriously. It is a
tragedy of over-education that any "educated" person can even ask such a
stupid question. Any child knows that he does not choose between equally
good alternatives rationally. There _is_ such a thing as "good taste",
and if you have it, you make some choices, and if you lack it, you make
other choices. Alex Braun clearly lacks good taste and needs _help_ in
making a choice between which car to purchase. This is laughable!
Yes, I also type very fast. Look at all the typos in that article, and
you also see that I did not care enough about it to proof-read it.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
* ······@cyberspace.org (Alex Braun)
| Eric, so you wrote this 3Kb piece only to state the obvious: "you had
| made the right choice if you were happy with it later". Are you
| retarded? Having other mental problems?
No, Alex the Retard, I wrote it to make fun of your quite silly request.
It seems that you picked up on the "made fun of" part, but not the "fun"
part. This is so tragic. My mailbox lit up with thank-you notes and
"ROTFL" comments this morning, so I know a lot of people have a working
humor module out there. It was written for them, not for you. Sorry.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Alex Braun wrote:
>
> Eric, so you wrote this 3Kb piece only to state the obvious
You post a question that's clearly flamebait then complain
about the answers?
> Are you
> retarded? Having other mental problems?
Ah - more flamebait.
Please don't top-post.
······@cyberspace.org (Alex Braun) wrote in message news:<···························@posting.google.com>...
> Eric, so you wrote this 3Kb piece only to state the obvious: "you had
> made the right choice if you were happy with it later". Are you
To make the best use of a programming language, you have to love it.
Only if you love it can you be really fluent in it. And only if you
believe in its value to you can you really love it. And only if
you're really fluent in it can you really believe in its value to you.
It's circular reasoning, just like with the kind of magic that
doesn't work unless you believe in it, and you can't believe in it
unless it works. It's the kind of circular reasoning commonly
abhorred by the kind of people who want the world to be simpler and
easier to calculate. But it's actually a much more complicated world,
and a very frequently applicable kind of reasoning.
The only really good way to measure the value of a programming
language is by what people actually accomplish with it, and how much
it costs them to accomplish those things. You can't isolate the value
of the programming language from the skill of the person using it, so
you have to accept the compound value of the two as the only
meaningful measure. Maybe one language is better because it attracts
better programmers. How can we ever be sure? Maybe, in the great
scheme of things, finding something you can be happy with is all that
really matters.
I find your anology flawed.
I would say the way a professional programmer would look at it is as
thus...
A carpenter/roofer has to nail 400 shingles to the roof by the end of
tommorrow. Does she use a sledgehammer with penny nails, a ball peen
hammer with railroad spikes, or a nail gun with with roofing nails?
After finishing the roofing job, another carpenter goes inside the house
with the intent of sanding and re-varnishing the kitchen cabinets. Does
he use a folded up piece of sand paper, a 60 pound floor sander, or an
electric hand sander?
Clearly some of the choices in the above scenarios would have been
absurd. However, had the scenario been different, the absurd choices
could have become the most reasonable. In a nutshell the carpenter was
choosing his/her tools based upon the task being performed.
Why do programmers, professional and hobbyist alike, have such a
difficult time grasping this concept? No single language is best for all
programming tasks. Programmers are worse than the Taliban or the the
Gestapo in this regard. i.e. If it isnt written thier own pet language,
then it's crap. I'm amazed that some of these twits managed to make it
through a university.
Yet the fact does remain that some languages are better for some tasks
than others. Of course one could choose a language based on ones own
aesthetic or sadistic predisposition, but the real professional looks at
the problem domain and chooses a tool from thier belt that best performs
the job.
Rant mode off...
That's the world as I see it anyways.
McDoobie
>>>>> "Caffiene" == Caffiene Junky <······@hotmail.com> writes:
Caffiene> I find your anology flawed.
Caffiene> I would say the way a professional programmer would look at it is as
Caffiene> thus...
Caffiene> A carpenter/roofer has to nail 400 shingles to the roof by the end of
Caffiene> tommorrow. Does she use a sledgehammer with penny nails, a ball peen
Caffiene> hammer with railroad spikes, or a nail gun with with roofing nails?
Caffiene> After finishing the roofing job, another carpenter goes inside the house
Caffiene> with the intent of sanding and re-varnishing the kitchen cabinets. Does
Caffiene> he use a folded up piece of sand paper, a 60 pound floor sander, or an
Caffiene> electric hand sander?
Caffiene> Clearly some of the choices in the above scenarios would have been
Caffiene> absurd. However, had the scenario been different, the absurd choices
Caffiene> could have become the most reasonable. In a nutshell the carpenter was
Caffiene> choosing his/her tools based upon the task being performed.
Caffiene> Why do programmers, professional and hobbyist alike, have such a
Caffiene> difficult time grasping this concept? No single language is best for all
Caffiene> programming tasks. Programmers are worse than the Taliban or the the
Caffiene> Gestapo in this regard. i.e. If it isnt written thier own pet language,
Caffiene> then it's crap. I'm amazed that some of these twits managed to make it
It's pretty hard to use a folded piece of sandpaper to hammer in nails
for your roof.
Computer languages don't have this kind of constraint since they can
all compute the same things. The difference is the level of effort
needed for each language. And sometimes it's faster/easier/better to
use the language you know but doesn't really fit the problem than to
learn a new language that is a better fit to the problem.
Ray
On Thu, 30 May 2002 17:05:32 GMT, Caffiene Junky <······@hotmail.com> wrote:
>I find your anology flawed.
Yet you can't find the correct spelling of ``caffeine'' and ``junkie''.
On Thu, 30 May 2002 17:05:32 GMT, Caffiene Junky <······@hotmail.com> wrote:
>I find your anology flawed.
Yet you can't find the correct spelling of ``caffeine'' in a dictionary.
Caffiene Junky <······@hotmail.com> writes:
> I find your anology flawed.
>
> I would say the way a professional programmer would look at it is as
> thus...
>
> A carpenter/roofer has to nail 400 shingles to the roof by the end of
> tommorrow. Does she use a sledgehammer with penny nails, a ball peen
> hammer with railroad spikes, or a nail gun with with roofing nails?
> After finishing the roofing job, another carpenter goes inside the house
> with the intent of sanding and re-varnishing the kitchen cabinets. Does
> he use a folded up piece of sand paper, a 60 pound floor sander, or an
> electric hand sander?
>
>
> Clearly some of the choices in the above scenarios would have been
> absurd. However, had the scenario been different, the absurd choices
> could have become the most reasonable. In a nutshell the carpenter was
> choosing his/her tools based upon the task being performed.
You're relating languages to individual tools. I guess the whole
industry makes that mistake, because a language usually comes packaged
as a program, like other programs which are indeed individual tools.
However, neither CL, ML, nor C are hammers, nail guns, nor sandpaper;
they are tool-belts. CL has a much better selection of tools on it,
and thus need not ever be the wrong tool for the job (the tools for the
job are hanging on the CL belt). Now, there are times when I've seen
carpenters take off their tool-belts to get into a tight space, but I
seldom see this; a carpenter usually feels naked without his favorite
tool-belt around his waist.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
"Duane Rettig" <·····@franz.com> wrote in message ··················@beta.franz.com...
>
> However, neither CL, ML, nor C are hammers, nail guns, nor sandpaper;
> they are tool-belts.
Item # 3021 - C Tool Belt Suggested Price $9.95 Our Price $6.50
A true classic, our C Tool Belt comes with all the tools you'll need
for fashioning quality software. Comfortable, natural material can
be draped around hips. Basic instruction manual includes directions
for making a buckle. Rock is made of genuine granite, the same material
used in many of the finest buildings in the world. Pointy stick has
built-in hardwood handle and may be used by left-handed or right-handed
people with equal ease.
Features: all hide construction
pocket for spare rock
holster for pointy stick
Spare rock sold separately. Not for sale to residents of
Massachusetts, California, or any other state with restrictions upon
ownership of rocks and/or pointy sticks.
Item # 5274 - Common Lisp Tool Belt Suggested Price $40,000. Our Price $10,000.
Our Common Lisp tool belt is designed with the tinkerer in mind. The
three-axis Bridgeport Series I Standard Mill (included) is located
on the hip pocket for easy access, while the high-speed Intaglio
Printer is tucked away in the back for more convenient carrying.
Detachable GPS may be worn on wrist.
Features: dual cutting heads -- water jet and plasma
Computer Numerical Control interface
CRC Handbook, OED, PDR, and DSM IV included
in documentation
Item # 38661 - C++ Tool Belt Suggested Price $100.00 Our Price $69.95
Make a fashion statement with our modern C++ Tool Belt. Features
genuine synthetic rock and over 3,000 custom made pointy sticks so
you'll always have exactly the right tool for the job. Belt comes
with heavy duty buckles, zippers, velcro, buttons, hook and eye
fasteners, snaps, frogs (both the fastener and the amphibian), clasps,
sequins, lace trim, and mounting points for clip-on suspenders.
Expansion kits of pointy sticks available.
Features: trendy colors
pocket for spare rock
holster for pointy stick
Note: Synthetic rock should not be used in situations where it may
come into contact with other objects such as the pointy stick.
Synthetic rock composed of man-made materials, repeated use may cause
skin irritation or death.
Caffiene Junky <······@hotmail.com> writes:
> Why do programmers, professional and hobbyist alike, have such a
> difficult time grasping this concept? No single language is best for all
> programming tasks. Programmers are worse than the Taliban or the the
> Gestapo in this regard. i.e. If it isnt written thier own pet language,
Can you point me to any studies or resources on the programming
language selection methodology employed by the Taliban or the Gestapo?
I had a look on citeseer, but couldn't find anything that looked
particularly relevant.
-dan "incidentally, you seem to have invoked Godwin's Law"
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Can you point me to any studies or resources on the programming
> language selection methodology employed by the Taliban or the Gestapo?
Since the Gestapo ignored Plankalkuel, arguably the most advanced
programming language of its time, they seem to have had an industry
standard approach of mediocrity.
--
Bored, now.
Lieven Marchand <···@wyrd.be>
Caffiene Junky <······@hotmail.com> writes:
> Why do programmers, professional and hobbyist alike, have such a difficult
> time grasping this concept?
it's not a difficult concept to grasp but for some it's a difficult concept to
let go of.
thi
Caffiene Junky <······@hotmail.com> writes:
> Of course one could choose a language based on ones own
> aesthetic or sadistic predisposition, but the real professional looks at
> the problem domain and chooses a tool from thier belt that best performs
> the job.
A small correction: choose the best tool, if it exists, or create it,
if it does not. And use all needed tools together!
> McDoobie
Wonderful. Thanks. Could you write a c.l.l. FAQ entry "Why should I
choose Lisp?"
Regards,
Alexey Dejneka
---
"You've said you removed a bug. Why has the code grown?"
I think that the tool analogy misses important aspects. A programming
language isn't the hammer, it's the nail :)
Or perhaps the choice of building style (wood or stone). What I mean
is that the coice of language becomes part of the product in a way
that the choice of tool doesn't.
--
Lennart Staflin <·····@lysator.liu.se>
"Caffiene Junky" <······@hotmail.com> wrote in message
····························@rwcrnsc52.ops.asp.att.net...
> Why do programmers, professional and hobbyist alike, have such a
> difficult time grasping this concept? No single language is best for all
> programming tasks.
I think you are confusing language here with a specified programming language. To solve
programming tasks you need a vocabulary and some sytax to express the solution. It is not
the rigourous sytax of the language which solves the problem, it is the application of
that syntax which does.
Take the example of a low-level device driver. Most people would say, "let's pick C or
assembler" its obviously the best language (because it maps directly to machine
addressing, and the hardware we are controlling invloves the low-level IO to memory
registers). But it is entirely possible to write the solution in Lisp and have it compile
down to a low level bit-twiddling code and emit the small device driver. It is not a
restriction of the language, its a restriction of actually having this functionality
(literally the functions and macros) in some Lisps. In fact I would like to have this C
like control of memory space in some parts of Lisp, and I would prefer to use Lisp because
of its syntax is much more expressive.
So this does not make sense to me when you say no best language because I know you are
saying programming-language-syntax. The language which is the most expressive and
understandable is the best choice for me.
Maybe as an example
Naive C example
#define UART_ADDRESS 0x300
#define UART_FIFO_READY_ADDR (UART_ADDRESS+0x10)
#define UART_FIFO_READY 0x00
#define UART_WRITE_FIFO_OUT 0x0d
int write_char (char c)
{
for (ready=0;(ready==0);;) {
if (read_uart(UART_ADDRESS,UART) == UART_FIFO_READY)
then ready = 1;
else sleep(.001);
}
return write_char_uart(UART_ADDRESS,UART_WRITE_FIFO_OUT,c);
}
Possible Lisp Version
(in-package :uart)
(define-memory-addessable-device uart
(:base-address #x300)
(:registers
((fifo-ready :offset #x04 :documentation "Value 0 - UART FIFO is available for write"
:type :unsigned32
:accessor fifo-readu
:values '((ready #x0) (busy #x1)))
(output :offset #x05 :type :unsigned8 :accessor output)))
(defddfun write-char ((uart uart) (char character))
(with-io-error-handler
(wait-until (fifo-ready uart) 'ready :timeout 1.0))
(write-register (output uart) char)))
There is no reason they could not both compile into something roughly the same. One just
has more language (vocabulary) around it.
Wade
>>>>> On Sun, 2 Jun 2002 10:43:06 -0600, Wade Humeniuk ("Wade") writes:
Wade> But it is entirely possible to write the solution in Lisp and have
Wade> it compile down to a low level bit-twiddling code and emit the small
Wade> device driver. It is not a restriction of the language, its a
Wade> restriction of actually having this functionality (literally the
Wade> functions and macros) in some Lisps. In fact I would like to have
Wade> this C like control of memory space in some parts of Lisp, and I
Wade> would prefer to use Lisp because of its syntax is much more
Wade> expressive.
Wade> So this does not make sense to me when you say no best language
Wade> because I know you are saying programming-language-syntax. The
Wade> language which is the most expressive and understandable is the best
Wade> choice for me.
Wade> Maybe as an example
Wade> Naive C example
Wade> #define UART_ADDRESS 0x300
Wade> #define UART_FIFO_READY_ADDR (UART_ADDRESS+0x10)
Wade> #define UART_FIFO_READY 0x00
Wade> #define UART_WRITE_FIFO_OUT 0x0d
Wade> int write_char (char c)
Wade> {
Wade> for (ready=0;(ready==0);;) {
Wade> if (read_uart(UART_ADDRESS,UART) == UART_FIFO_READY)
Wade> then ready = 1;
Wade> else sleep(.001);
Wade> }
Wade> return write_char_uart(UART_ADDRESS,UART_WRITE_FIFO_OUT,c);
Wade> }
Wade> Possible Lisp Version
Wade> (in-package :uart)
Wade> (define-memory-addessable-device uart
Wade> (:base-address #x300)
Wade> (:registers
Wade> ((fifo-ready :offset #x04 :documentation "Value 0 - UART FIFO is available for write"
Wade> :type :unsigned32
Wade> :accessor fifo-readu
Wade> :values '((ready #x0) (busy #x1)))
Wade> (output :offset #x05 :type :unsigned8 :accessor output)))
Wade> (defddfun write-char ((uart uart) (char character))
Wade> (with-io-error-handler
Wade> (wait-until (fifo-ready uart) 'ready :timeout 1.0))
Wade> (write-register (output uart) char)))
Actual Lisp version:
(defconstant %merlin-io-board-base-address #o10000000000)
(defconstant %merlin-serial-poll-register #o00400270000) ; poll reg, for return values
(defwiredfun read-polled-register (board-base-address offset)
(declare (values byte-result))
(setq board-base-address (%make-physical-address board-base-address))
(let ((address-to-write (sys:%pointer-plus board-base-address offset))
(address-to-read (sys:%pointer-plus board-base-address %merlin-serial-poll-register)))
(sys:%memory-write address-to-write 0)
(loop for result = (sys:%memory-read address-to-read :cycle-type sys:%memory-raw)
while (type-member result ; h/w returns a flonum if the operation's not
dtp-single-float) ; yet complete.
finally (return (ldb (byte 8 0) result)))))
On Thu, 30 May 2002 17:05:32 GMT, Caffiene Junky <······@hotmail.com>
wrote:
> could have become the most reasonable. In a nutshell the carpenter was
> choosing his/her tools based upon the task being performed.
How much freedom in choosing their tools do carpenters have, particularly
when such tools are provided by the company they work for?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
* Paolo Amoroso
| How much freedom in choosing their tools do carpenters have, particularly
| when such tools are provided by the company they work for?
Every analogy breaks down sooner or later because things are not exactly
the same. Chefs bring their knives with them. Cleaners have their own
personal arsenal. Professors bring their curriculum with them. Hm, I
(unintentionally) kept thinking about dangerous things. Perhaps because
carpenters have dangerous tools and Common Lisp in the best of hands can
be lethal to bugs.
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
Erik Naggum <····@naggum.net> writes:
> * Paolo Amoroso
> | How much freedom in choosing their tools do carpenters have, particularly
> | when such tools are provided by the company they work for?
>
> Every analogy breaks down sooner or later because things are not exactly
> the same. Chefs bring their knives with them. Cleaners have their own
> personal arsenal. Professors bring their curriculum with them. Hm, I
> (unintentionally) kept thinking about dangerous things. Perhaps because
> carpenters have dangerous tools and Common Lisp in the best of hands can
> be lethal to bugs.
*I* always bring a late-eighties IBM keyboard with me. I
haven't seen anything of similar quality made within the last 10
years.
Note that a keyboard can also be counted as a dangerous
tool. The IBM ones even more than usual, as they are quite heavy :-)
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
Paolo Amoroso <·······@mclink.it> writes:
> On Thu, 30 May 2002 17:05:32 GMT, Caffiene Junky <······@hotmail.com>
> wrote:
>
> > could have become the most reasonable. In a nutshell the carpenter was
> > choosing his/her tools based upon the task being performed.
>
> How much freedom in choosing their tools do carpenters have, particularly
> when such tools are provided by the company they work for?
All of the carpenters I know choose their own tools. And none of the
building contractors I know supply the carpenters they hire any of the
tools they normally put on their tool-belts, nor do they force these
contractees to work with certain specified tools (unless there is a
requirement for a special tool for a specific job). Usually a carpenter
will choose his own hammer by weight, fit, and balance, and nobody forces
him to use another hammer, unless there are special circumstances (but
usually the carpenter is competent enough to do amazing things with his
hammer, or else he has enough wisdom to chose something else. Usually,
though, such a choice depends less on whether the hammer was the right
tool for the job, but whether or not the job will actually break the
hammer.
Yes, we're still talking about Lisp. I've been amazed to watch carpenters
drive nails from any angle, with either right or left hand, sometimes when
there isn't enough room above the nail to even get the whole hammer head
squarely onto the nail. I've also seen them do things that I had been
told were not supposed to be done with hammers, like using them as a
pry-bar or as a claw (to break wood into pieces). The point is that
these carpenters are extemely comfortable with their own tools, and
know them very well, and know their limitations. We should acquire the
same skills with our own chosen programming languages.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Alex Braun wrote:
> For what types of projects should one choose Lisp and for what types
> of projects should one choose *ML? Is there a set of clear criteria?
> Are these groups of languages basically two different tools for two
> different jobs, or are they essentially competing for the same
> "ecological niches", such as for example machine learning, expert
> systems, compilers, etc.?
This is a question without an answer. Which language is appropriate for a
given task is more dependent on what YOU perceive as the appropriate
valuation function on features of the language and the problem. Odd
analogies like "ecological niche" do not help either. One person's niche
is another's barren wasteland. As far as having the "same" problem spaces,
I would tend to think that it is the same as with other languages - there
is some overlap, and some non-overlap, and the perceptions of these will
change with each person.
When you have a question that HAS an actual answer, come back. Otherwise
be a bit more honest:
"I want to start a flame war about whether ML threatens Lisp. With any
luck, we'll get into a big argument about dynamic vs. static typing and
whether macros make any difference. Please couch all of this in academic
mumbo-jumbo so I can appear to be erudite while being critical and
condescending."
It's bullshit. Go away, troll...
faa
Alex Braun wrote:
> For what types of projects should one choose Lisp and for what types
> of projects should one choose *ML? Is there a set of clear criteria?
> Are these groups of languages basically two different tools for two
> different jobs, or are they essentially competing for the same
> "ecological niches", such as for example machine learning, expert
> systems, compilers, etc.?
The two languages are essentially the same, with complementary weaknesses:
-- Lisp lacks a good type-checking system
-- ML lacks a read-eval-print loop and macros
A combination of the two would be dynamite. I produced a strongly typed
dialect of Lisp a few years ago, called Nisp, that has quite a few
flaws; I still use it, and it's available on my web site
(http://www.cs.yale.edu/~dvm) but its type system is not nearly as
powerful or well behaved as ML's. I'm still working on an improved
version, but reconciling polymorphic types and inductive data types with
Lisp programming style is surprisingly difficult.
-- Drew McDermott
Drew McDermott <··············@yale.edu> writes:
> Alex Braun wrote:
>
> > For what types of projects should one choose Lisp and for what types
> > of projects should one choose *ML? Is there a set of clear criteria?
> > Are these groups of languages basically two different tools for two
> > different jobs, or are they essentially competing for the same
> > "ecological niches", such as for example machine learning, expert
> > systems, compilers, etc.?
>
> The two languages are essentially the same, with complementary weaknesses:
> -- Lisp lacks a good type-checking system
> -- ML lacks a read-eval-print loop and macros
Many ML implementations have a REPL. Macros are not nearly as
essential as you might think, but if you really think you need them,
then have a look at things like MetaML. You're at the source, just
talk to Walid.
--
-Matthias
On Sat, Jun 01, 2002 at 09:48:08AM -0400, Matthias Blume wrote:
> Many ML implementations have a REPL.
They have a read-typecheck-eval-print-loop to be precise. However, this is
not equivalent to the Lisp REPL due to generativity of types (and is, in fact,
less powerful as a result).
Consider the following inputs to the SML/NJ RTEPL:
- datatype foo = One | Two;
datatype foo = One | Two
- fun bar x = case x of One => Two | _ => One;
val bar = fn : foo -> foo
- bar One;
val it = Two : foo
- datatype foo = One | Two | Three;
datatype foo = One | Three | Two
- bar One;
stdIn:26.1-26.8 Error: operator and operand don't agree [tycon mismatch]
operator domain: ?.foo
operand: foo
in expression:
bar One
Generativity is useful for data abstraction but sacrifices redefinition.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sat, Jun 01, 2002 at 09:48:08AM -0400, Matthias Blume wrote:
>
>>Many ML implementations have a REPL.
>
>
> They have a read-typecheck-eval-print-loop to be precise. However, this is
> not equivalent to the Lisp REPL due to generativity of types (and is, in fact,
> less powerful as a result).
I don't know if "powerful" is the right word. Lisp's REPL is basically
just extremely convenient, if impossible to make into coherent logical
sense. That's what keeps ML and Haskell from having a decent REPL; they
can't bring themselves to allow the user to just redefine whatever he
wants and hope for the best.
-- Drew McDermott
In article <·····················@mapcar.org>,
Matthew Danish <·······@andrew.cmu.edu> wrote:
> stdIn:26.1-26.8 Error: operator and operand don't agree [tycon mismatch]
Oh! I've seen "Tycon Mismatch" as the name of a team in the last couple
of ICFP contests. And, they were using SML.
What does it mean, exactly?
-- Bruce
On Sun, Jun 02, 2002 at 01:48:24PM +1200, Bruce Hoult wrote:
> In article <·····················@mapcar.org>,
> Matthew Danish <·······@andrew.cmu.edu> wrote:
>
> > stdIn:26.1-26.8 Error: operator and operand don't agree [tycon mismatch]
>
> Oh! I've seen "Tycon Mismatch" as the name of a team in the last couple
> of ICFP contests. And, they were using SML.
>
> What does it mean, exactly?
>
It means: "Welcome to ML Hell" generally, but also type constraint
mismatch IIRC.
Here it means that the old 'foo' is not the new 'foo', which is true
certainly, but I carefully wrote them so that the second definition
was a superset of the first. So there's no real reason why 'bar' shouldn't
go on working except for generativity (and static semantics in general).
(I had a huge debate about this and related matters with someone who insisted
that dynamically typed systems were a subset of statically typed systems)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
<·······@andrew.cmu.edu> wrote in message ··························@mapcar.org...
>
> (I had a huge debate about this and related matters with someone who insisted
> that dynamically typed systems were a subset of statically typed systems)
>
Static typers are a weird bunch.
If your static type system *includes* the ability to do dynamic type checks,
and then you *turn off* the static type checks by making everything a union
type, then it behaves like a dynamically typed system. So, their argument
goes, dynamically typed systems are a subset of statically typed.
A statically typed system has *more ways* to describe under exactly
what conditions your program will *not* work. So, their argument goes,
statically typed systems are `more expressive' than dynamically typed
ones. This despite the fact more *programs* run under a dynamically
typed system.
You can defeat the type checking at compile time by making everything
a union. So, their argument goes, the errors you get at run time
aren't `type' errors, but rather `pattern matching' or `union discrimination'
errors. Thus the static typing `worked'.
"Joe Marshall" <·············@attbi.com> writes:
> Static typers are a weird bunch.
Sigh. This standard debate was bound to reoccur.
> If your static type system *includes* the ability to do dynamic type checks,
Which they must if they are to be useful at all for real programming. In the
presence of type heirarchies with subtypes, it is impossible to avoid dynamic
checks completely.
> and then you *turn off* the static type checks by making everything a union
> type,
Having typing heirarchies is not the same as turing off type checking. A
static language system can only detect and report on what it can during static
analysis, and of necessity must defer the rest to runtime.
> then it behaves like a dynamically typed system.
If you so happen to choose to program using the root union or "any" type you
can coindicentally get most of the effects of a dynamic language -- at least
the runtime type checking part.
Now whether or not you wish to actually classify static languages as a
superset is another issue. Actual language systems tend to be realizations of
particular programming philosphies, and optimize support for those philsophies
such that programming in them are dramatically different experiences.
For me, I tend to pick one or the other based on the problem at
hand. Sometimes I need to be anal about correctness, and prefer the pickiness
of a statically typed system. Othertimes I need to get things done quickly,
and a dynamic language suffices admirably.
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
So, their argument
> goes, dynamically typed systems are a subset of statically typed.
>
> A statically typed system has *more ways* to describe under exactly
> what conditions your program will *not* work. So, their argument goes,
> statically typed systems are `more expressive' than dynamically typed
> ones. This despite the fact more *programs* run under a dynamically
> typed system.
>
> You can defeat the type checking at compile time by making everything
> a union. So, their argument goes, the errors you get at run time
> aren't `type' errors, but rather `pattern matching' or `union discrimination'
> errors. Thus the static typing `worked'.
"Ray Blaak" <·····@telus.net> wrote in message ··················@telus.net...
> "Joe Marshall" <·············@attbi.com> writes:
> > Static typers are a weird bunch.
>
> Sigh. This standard debate was bound to reoccur.
I didn't think we debated the weirdness of static type aficionados.
> > If your static type system *includes* the ability to do dynamic type checks,
>
> Which they must if they are to be useful at all for real programming.
Go figure.
> In the presence of type heirarchies with subtypes, it is impossible
> to avoid dynamic checks completely.
>
> > and then you *turn off* the static type checks by making everything a union
> > type,
>
> Having typing heirarchies is not the same as turing off type checking.
Yes, but making *everything* a union of some all-encompassing type means
that your static type checker must of necessity defer *all* type resolution
to runtime. Since *no* non-trivial type resolution is done at compile
time, there is nothing non-trivial that is `statically' checked.
This isn't to say that you've turned off *all* type checking (because
it will happen at run time), but that you've deferred *all* type analysis
to run time. Thus your type checks cannot be called `static' without
broadening the definition of `static' to a meaningless concept.
>
> Now whether or not you wish to actually classify static languages as a
> superset is another issue.
Since statically typed languages and non-statically typed languages are
equivalent to a turing machine, I can't see why either would be a superset
of the other.
Bruce Hoult <·····@hoult.org> writes:
> In article <·····················@mapcar.org>,
> Matthew Danish <·······@andrew.cmu.edu> wrote:
>
> > stdIn:26.1-26.8 Error: operator and operand don't agree [tycon mismatch]
>
> Oh! I've seen "Tycon Mismatch" as the name of a team in the last couple
> of ICFP contests. And, they were using SML.
>
> What does it mean, exactly?
"TYpe CONstructor mismatch".
--
-Matthias
Matthew Danish <·······@andrew.cmu.edu> writes:
> - datatype foo = One | Two;
> - fun bar x = case x of One => Two | _ => One;
> - datatype foo = One | Two | Three;
> datatype foo = One | Three | Two
> - bar One;
> stdIn:26.1-26.8 Error: operator and operand don't agree [tycon mismatch]
> ...
> Generativity is useful for data abstraction but sacrifices redefinition.
This doesn't appear to me to be inherent to ML's static typing; after
all, redefining foo in a slightly different environment (your editor,
changing its definition in a source file) does not have this problem.
Suppose the RTEPL were to automatically recompile any affected
definitions when you changed the definition of a type. Would the new
behavior be worse in any way?
Matthias Blume <········@shimizu-blume.com> writes:
> Drew McDermott <··············@yale.edu> writes:
>
> > Alex Braun wrote:
> >
> > > For what types of projects should one choose Lisp and for what types
> > > of projects should one choose *ML? Is there a set of clear criteria?
> > > Are these groups of languages basically two different tools for two
> > > different jobs, or are they essentially competing for the same
> > > "ecological niches", such as for example machine learning, expert
> > > systems, compilers, etc.?
> >
> > The two languages are essentially the same, with complementary weaknesses:
> > -- Lisp lacks a good type-checking system
> > -- ML lacks a read-eval-print loop and macros
>
> Many ML implementations have a REPL. Macros are not nearly as
> essential as you might think, but if you really think you need them,
> then have a look at things like MetaML. You're at the source, just
> talk to Walid.
By the same token `datatype' and friends are not nearly as essential
as you might think once you have powerful macros. Just look at the
Common Lisp macro system to see how you could easily replace most of
the uses of the *ML type systems. :)
All in all what Drew McDermott said is true. There are complementary
weaknesses. What you really want is Common Lisp with `type checking'.
Only `type checking' is not enough.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> By the same token `datatype' and friends are not nearly as essential
> as you might think once you have powerful macros. Just look at the
> Common Lisp macro system to see how you could easily replace most of
> the uses of the *ML type systems. :)
Great example. Try changing a macro definition in Lisp and see how
all your previously compiled code magically gets updated. NOT.
--
-Matthias
Matthias Blume <········@shimizu-blume.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > By the same token `datatype' and friends are not nearly as essential
> > as you might think once you have powerful macros. Just look at the
> > Common Lisp macro system to see how you could easily replace most of
> > the uses of the *ML type systems. :)
>
> Great example. Try changing a macro definition in Lisp and see how
> all your previously compiled code magically gets updated. NOT.
AFAIK, this is not the case in *ML languages either when you change a
'datatype' definition.
The bottom line is still this:
The best language would be Common Lisp with better type manipulation.
*ML languages threw the baby away with the bathwater.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Matthias Blume <········@shimizu-blume.com> writes:
>
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> >
> > > By the same token `datatype' and friends are not nearly as essential
> > > as you might think once you have powerful macros. Just look at the
> > > Common Lisp macro system to see how you could easily replace most of
> > > the uses of the *ML type systems. :)
> >
> > Great example. Try changing a macro definition in Lisp and see how
> > all your previously compiled code magically gets updated. NOT.
>
> AFAIK, this is not the case in *ML languages either when you change a
> 'datatype' definition.
Of course not. All I was trying to say is that simulating datatypes
with macros does not solve the problem "just because it is Lisp".
So while macros are not worse in this respect, they aren't better either.
> The bottom line is still this:
>
> The best language would be Common Lisp with better type manipulation.
> *ML languages threw the baby away with the bathwater.
The real bottom line is that the baby is already out. There are lots
of ways of defining A to be some B in Lisp so that redefining it to be
some C (<> B) later does not work "as if A had been defined to be C in
the first place". Macros are one example, and pretty much any
toplevel expression "consuming" a variable's value (as opposed to just
capturing the variable), is another.
ML has merely taken this to one of the possible logical extremes,
making all toplevel definitions affect only the future, never the
past. The other logical extreme where one can redefine everything at
any time and have it work "as if it had been defined using the latest
definition in the first place" requires restricting oneself to a
subset of Lisp with no macros, no "usual integrations" or other
"declarations", and only syntactic values toplevel.
I personally prefer the way ML deals with this, the reason being that
the treatment is uniform across all kinds of definitions. The
"downside" of this (not working quite as flexibly as some
redefinitions -- but nowhere near all -- do in Lisp) has never
bothered me because I personally have little use for a REPL when
programming.
--
-Matthias
>>>>> "Matthias" == Matthias Blume <········@shimizu-blume.com> writes:
Matthias> bothered me because I personally have little use for a REPL when
Matthias> programming.
Ewww. That's one of the key reasons I use Lisp. Makes debugging and
general exploring very nice. That's why I like Matlab too, despite
all it's other faults. I hate edit/compile/link/run/debug.
Ray
Matthias Blume wrote:
>
> ML has merely taken this to one of the possible logical extremes,
> making all toplevel definitions affect only the future, never the
> past. The other logical extreme where one can redefine everything at
> any time and have it work "as if it had been defined using the latest
> definition in the first place" requires restricting oneself to a
> subset of Lisp with no macros, no "usual integrations" or other
> "declarations", and only syntactic values toplevel.
>
> I personally prefer the way ML deals with this, the reason being that
> the treatment is uniform across all kinds of definitions. The
> "downside" of this (not working quite as flexibly as some
> redefinitions -- but nowhere near all -- do in Lisp) has never
> bothered me because I personally have little use for a REPL when
> programming.
>
Yes, it is true that occasionally in Lisp one finds that some
redefinition has changed something mysterious, and one has to start Lisp
again. However,
A. It hardly seems like a reasonable response to this situation to
*require* a restart when something changes.
B. Dealing with redefinitions is a large and complex problem, and the
case of defining and running a single program is only a special case.
As an example of B, suppose one has a little DB of some kind (assume it
fits in primary memory). There are indexing structures that make access
to the DB more efficient, which are recomputed whenever the DB changes.
However, it's not a good idea to recompute them whenever there's a
change, because there might be several changes before the next need for
the index. (Picture the DB as consisting of several independently
changeable chunks.) What you need is a mechanism that recomputes the
indexes the next time they are needed, provided one of the underlying
data structures they are based on has changed.
Surely this is the same problem in both Lisp and ML; the inflexibility
of the ML REPL doesn't "help." (Of course, ML beats Haskell here, which
could make the indexes be lazy functions of the DB pieces, but wouldn't
allow you to change a DB piece without -- you guessed it -- restarting
the program.)
-- Drew McDermott
Drew McDermott wrote:
>
> A combination of the two would be dynamite. I produced a strongly typed
> dialect of Lisp a few years ago, called Nisp, that has quite a few...
Wow, you are the perfect sounding board, a True Lisper who loves strong
typing (of variables, should I qualify?)
Many Lispers see untyped variables as not just "not a problem" but
furthermore as "an advantage", generally in its facilitation of RAD. But
your position is clear insofar as you actually cooked up Nisp.
At the risk of kicking off a firestorm, I'd love to hear why a dedicated
Lisper loves strong typing so well.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
"Kenny Tilton" <·······@nyc.rr.com> wrote in message ······················@nyc.rr.com...
>
>
> Drew McDermott wrote:
> >
> > A combination of the two would be dynamite. I produced a strongly typed
> > dialect of Lisp a few years ago, called Nisp, that has quite a few...
>
> Wow, you are the perfect sounding board, a True Lisper who loves strong
> typing (of variables, should I qualify?)
>
> Many Lispers see untyped variables as not just "not a problem" but
> furthermore as "an advantage", generally in its facilitation of RAD. But
> your position is clear insofar as you actually cooked up Nisp.
>
> At the risk of kicking off a firestorm, I'd love to hear why a dedicated
> Lisper loves strong typing so well.
Common Lisp *is* strongly typed: you cannot apply primitive operations
to data of the incorrect type.
Examples of weakly typed languages are assembly code, BCPL, and Intercal.
Some people consider C to be weakly typed.
Static typing usually refers to performing type checks at compile time
whereas dynamic typing refers to performing type checks at run time.
However, static typing does not preclude there being runtime type checks.
Conversely dynamic typing does not preclude there being compile time type
checks. A type checker can divide the code into three categories: that
code which is provably correct, that code which is provably wrong, and
undecided. Where static and dynamic type checking differs is in the
treatment of the undecided set. A static type checker will complain about
undecided code and ask the user for proof of correctness (type declarations).
A dynamic type checker will accept undecided code and complain when a
counter-example is shown (run time error).
A sufficiently powerful static type system can mimic dynamic typing
via a `union' type (and the trick of renaming those exceptions that
get raised at run time to be `pattern resolution errors', thus there
*are* no run-time `type' errors). A sufficiently powerful dynamic
type system can mimic static typing (imagine a hairy type inferencing
program that returns one of three values, :correct, :incorrect, and
:undecided. Now set up the evalhook to run the inferencer on your
program and have it refuse to call eval until the inferencer produces
:correct. If you are disciplined, you don't even need to do *that*,
just don't run programs that don't satisfy the inferencer.)
It is hard to reconcile static typing with polymorphic languages such
as lisp, especially in the presence of higher-order procedures. The
Programming Systems Research Group http://www.psrg.lcs.mit.edu/research.html
worked on FX, which is supposed to be a statically
typable lisp-like language with hairy type inferencing. My understanding
is that there were several problems that were never fully resolved.
On Sat, Jun 01, 2002 at 07:01:58PM +0000, Joe Marshall wrote:
> A sufficiently powerful static type system can mimic dynamic typing
> via a `union' type (and the trick of renaming those exceptions that
> get raised at run time to be `pattern resolution errors', thus there
> *are* no run-time `type' errors).
I've considered previously this somewhat at depth and came up with the
following counterexample (in SML/NJ):
exception Person of string
exception Tree of string
fun is_person (Person (_)) = true
| is_person _ = false
val v1 = is_person (Person "John") (* => true *)
val v2 = is_person (Tree "oak") (* => false *)
exception Person of string * int
val v3 = is_person (Person ("John", 20))
(* 'v3' should be 'true' if this is truely a dynamic typing mechanism *)
Here I use the 'exn' type as my 'union' type, but still I can't redefine
'Person' without generativity setting in. A dynamically typed system
such as CLOS would allow this change, and still recognize 'Person'.
What do you think?
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <·····················@mapcar.org>, ·······@andrew.cmu.edu
wrote:
> On Sat, Jun 01, 2002 at 07:01:58PM +0000, Joe Marshall wrote:
> > A sufficiently powerful static type system can mimic dynamic typing
> > via a `union' type (and the trick of renaming those exceptions that
> > get raised at run time to be `pattern resolution errors', thus there
> > *are* no run-time `type' errors).
>
> I've considered previously this somewhat at depth and came up with the
> following counterexample (in SML/NJ):
>
> exception Person of string
> exception Tree of string
>
> fun is_person (Person (_)) = true
> | is_person _ = false
>
> val v1 = is_person (Person "John") (* => true *)
>
> val v2 = is_person (Tree "oak") (* => false *)
>
> exception Person of string * int
>
> val v3 = is_person (Person ("John", 20))
> (* 'v3' should be 'true' if this is truely a dynamic typing mechanism *)
>
>
> Here I use the 'exn' type as my 'union' type, but still I can't redefine
> 'Person' without generativity setting in. A dynamically typed system
> such as CLOS would allow this change, and still recognize 'Person'.
> What do you think?
I think this is an aspect of your implementation, not of the language.
Dylan is dynamically typed, but you could not compile a translation of
the above code because you would get an error saying that Person is
multiply-defined.
-- Bruce
On Sun, Jun 02, 2002 at 03:47:27PM +1200, Bruce Hoult wrote:
> I think this is an aspect of your implementation, not of the language.
CLHS 4.3.6
And generativity is very much a property of SML, a distinguishing feature
of MLs in general.
> Dylan is dynamically typed, but you could not compile a translation of
> the above code because you would get an error saying that Person is
> multiply-defined.
It's more of a spectrum rather than a solid yes-or-no whether a language
is dynamically typed or not. In this case, CLOS is clearly more dynamic
than Dylan.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <·····················@mapcar.org>,
Matthew Danish <·······@andrew.cmu.edu> wrote:
> On Sun, Jun 02, 2002 at 03:47:27PM +1200, Bruce Hoult wrote:
> > I think this is an aspect of your implementation, not of the language.
>
> CLHS 4.3.6
>
> And generativity is very much a property of SML, a distinguishing feature
> of MLs in general.
Can you define "generativity" for me?
> > Dylan is dynamically typed, but you could not compile a translation of
> > the above code because you would get an error saying that Person is
> > multiply-defined.
>
> It's more of a spectrum rather than a solid yes-or-no whether a language
> is dynamically typed or not. In this case, CLOS is clearly more dynamic
> than Dylan.
That seems like a non-sequiter, in two ways.
First, CLOS isn't a language, it's an object system that is part of
Common Lisp. The object system within Dylan is nearly identical.
Second, Common Lisp is certainly more dynamic than Dylan in that, for
example, it is often used interactively and allows redefinition of
things. There are Dylan environments in which you can do incremental
and interactive programming, but they work differently in that if you
present a new definition for something then it is regarded as a new
version (in the sense of cvs) and any other definitions that depend on
it are recompiled in a data flow-driven way.
This is not the same thing as "dynamically typed" -- the subject of this
discussion -- in which respect the two languages are identical.
-- Bruce
On Sun, Jun 02, 2002 at 06:45:52PM +1200, Bruce Hoult wrote:
> In article <·····················@mapcar.org>,
> Matthew Danish <·······@andrew.cmu.edu> wrote:
>
> > On Sun, Jun 02, 2002 at 03:47:27PM +1200, Bruce Hoult wrote:
> > > I think this is an aspect of your implementation, not of the language.
> >
> > CLHS 4.3.6
> >
> > And generativity is very much a property of SML, a distinguishing feature
> > of MLs in general.
>
> Can you define "generativity" for me?
Generation of unique type identifier every time a type is defined. ML actually
uses this (often a number) rather than the name to keep track of types.
> First, CLOS isn't a language, it's an object system that is part of
CL + CLOS, if you must
> Common Lisp. The object system within Dylan is nearly identical.
Apparently not in some very important matters.
> Second, Common Lisp is certainly more dynamic than Dylan in that, for
> example, it is often used interactively and allows redefinition of
> things. There are Dylan environments in which you can do incremental
> and interactive programming, but they work differently in that if you
> present a new definition for something then it is regarded as a new
> version (in the sense of cvs) and any other definitions that depend on
> it are recompiled in a data flow-driven way.
Sounds an awful lot like CM, the SML compilation manager. And this still
requires the recompilation of dependent definitions, which CLOS doesn't.
> This is not the same thing as "dynamically typed" -- the subject of this
> discussion -- in which respect the two languages are identical.
The reason why I regard it as an aspect of "dynamic typing" whether
redefinition of types is supported or not is that it involves changing the
type-system (the type-system being all the types you have established or were
given), and implies that types can be modified (or in other words, are
"dynamic").
Remember how I said above that there is a spectrum of options--some more
dynamic, some more static--it's not black and white.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> writes:
> On Sun, Jun 02, 2002 at 06:45:52PM +1200, Bruce Hoult wrote:
> > In article <·····················@mapcar.org>,
> > Matthew Danish <·······@andrew.cmu.edu> wrote:
> >
> > > On Sun, Jun 02, 2002 at 03:47:27PM +1200, Bruce Hoult wrote:
> > > > I think this is an aspect of your implementation, not of the language.
> > >
> > > CLHS 4.3.6
> > >
> > > And generativity is very much a property of SML, a distinguishing feature
> > > of MLs in general.
> >
> > Can you define "generativity" for me?
>
> Generation of unique type identifier every time a type is defined. ML actually
> uses this (often a number) rather than the name to keep track of types.
This is somewhat confused. The identity is associated with type
*constructors*, which then translates to types constructed by those
constructors. And not every definition of a type constructor is
generative in (Standard) ML: only datatype definitions and abstract
type definitions are generative.
To understand the difference between non-generative and generative
definitions, consider these two SML snippets:
1. generative type constructor (via datatype declaration):
datatype t = T of int
2. non-generative type constructor (aka "type abbreviation):
type t = int
fun T (x : int) : t = x
I threw in a function T for good measure in case 2. to make it more
similar to 1.
In both examples, there are two type(-constructor) names "int" and "t".
In both cases you can construct a t from an int by applying T to it.
But in the former case, t and int are not the same, so
T 3 + 4
is a type error. In the second case, however, writing
T 3 + 4
gives you 7.
> Sounds an awful lot like CM, the SML compilation manager. And this still
> requires the recompilation of dependent definitions, which CLOS doesn't.
Just for the record: The standard example of where redefining
something in Lisp requires recompiling all of its uses is a macro
definition. So the problem does not go away just by avoiding
generative type definitions. (In fact, the way scoping works in ML,
no toplevel "re"definition affects the past the way it does in Lisp.
This is entirely unrelated to typing issues.)
--
-Matthias
·······@andrew.cmu.edu writes:
> On Sat, Jun 01, 2002 at 07:01:58PM +0000, Joe Marshall wrote:
> > A sufficiently powerful static type system can mimic dynamic typing
> > via a `union' type (and the trick of renaming those exceptions that
> > get raised at run time to be `pattern resolution errors', thus there
> > *are* no run-time `type' errors).
>
> I've considered previously this somewhat at depth and came up with the
> following counterexample (in SML/NJ):
> [ counterexample abbreviated ]
> exception Person of string
> exception Tree of string
> fun is_person (Person (_)) = true
> | is_person _ = false
> exception Person of string * int
> val v3 = is_person (Person ("John", 20))
> (* 'v3' should be 'true' if this is truly a dynamic typing mechanism *)
>
> Here I use the 'exn' type as my 'union' type, but still I can't redefine
> 'Person' without generativity setting in. A dynamically typed system
> such as CLOS would allow this change, and still recognize 'Person'.
> What do you think?
I think that if you are right, it leads to the conclusion that Python
(the language, not the Lisp compiler) is statically typed.
(Keep in mind that in Python, as in most languages in the C family, 0
is false, 1 is true, and these are the canonical representations of
truth and falsity returned by things like 'not' and 'isinstance'.)
Python 2.1.1 (#2, Dec 19 2001, 12:19:22)
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> class Borscht:
... pass
...
>>> class isinstancer:
... def __init__(self, aclass): self.aclass = aclass
... def inspect(self, object): return isinstance(object, self.aclass)
...
>>> borscht_tester = isinstancer(Borscht)
>>> bowl = Borscht()
>>> borscht_tester.inspect(bowl)
1
>>> borscht_tester.inspect(37)
0
>>> class Borscht:
... pass
...
>>> bowltwo = Borscht()
>>> borscht_tester.inspect(bowltwo)
0
In Python, creating a new class of the same name simply creates a new
class, rather than redefining your old class, just as in ML, creating
a new variant type with the same name simply creates a new variant
type. Things with references to the old type or the old class will
treat items of the new type or class as not being a member thereof.
If you try to translate the ML code directly to Python, it will
confusingly appear to work.
def is_borscht(obj): return isinstance(obj, Borscht)
will, at run-time, look up whatever is bound to the name Borscht in
globals; so if you define a new class Borscht as I did above, it will
return true for instances of the new class. (But it will return false
for any instances left over from the old class.)
In article <·················@nyc.rr.com>, Kenny Tilton wrote:
>
>
> Drew McDermott wrote:
>>
>> A combination of the two would be dynamite. I produced a strongly typed
>> dialect of Lisp a few years ago, called Nisp, that has quite a few...
>
> Wow, you are the perfect sounding board, a True Lisper who loves strong
> typing (of variables, should I qualify?)
>
> Many Lispers see untyped variables as not just "not a problem" but
> furthermore as "an advantage", generally in its facilitation of RAD. But
> your position is clear insofar as you actually cooked up Nisp.
>
> At the risk of kicking off a firestorm, I'd love to hear why a dedicated
> Lisper loves strong typing so well.
>
Are you talking about static typing? I have had lots of experience
with CMUCL's strong typing, reciently. It is always telling me I
cannot change this to that. I then figue out what I did wrong.
Now static typing is completely different. You decide what all your
type's(data structures) look like as the first step in program design,
then if you need to change them half way through lots of stuff needs
to be fixed. If you have not solved this problem at least twice befor
you will probably make some mistakes in your types.
Now from what I have seen here, read about and to a small extent done
"the lisp way" is to get a program working correctly and if it is fast
enough good. If it is not fast enough profile then optimize until it
is fast enough.
I do prefer the lisp way.
marc
ps It has been a while since I studdied this stuff so please take all
facts with a grain of salt.
> --
>
> kenny tilton
> clinisys, inc
> ---------------------------------------------------------------
> "Harvey has overcome not only time and space but any objections."
> Elwood P. Dowd
Marc Spitzer wrote:
>
> In article <·················@nyc.rr.com>, Kenny Tilton wrote:
> >
> >
> > Drew McDermott wrote:
> >>
> >> A combination of the two would be dynamite. I produced a strongly typed
> >> dialect of Lisp a few years ago, called Nisp, that has quite a few...
> >
> > Wow, you are the perfect sounding board, a True Lisper who loves strong
> > typing (of variables, should I qualify?)
> >
> > Many Lispers see untyped variables as not just "not a problem" but
> > furthermore as "an advantage", generally in its facilitation of RAD. But
> > your position is clear insofar as you actually cooked up Nisp.
> >
> > At the risk of kicking off a firestorm, I'd love to hear why a dedicated
> > Lisper loves strong typing so well.
> >
>
> Are you talking about static typing?
The Gotcha Squad strikes! Look guys, the OP said: "I produced a strongly
typed dialect of Lisp a few years ago" and I knew what he meant, why not
make the same effort?
Because I might not know the difference? In my reply I mention "strong
typing ... of variables" and "untyped variables"... only the third ref
lazily mentions only "strong typing"... hello?
Btw, Lisp is not statically typed? What about "3"?
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Well, I've wrestled with reality for thirty-five years, Doctor,
and I'm happy to state I finally won out over it."
Elwood P. Dowd
In article <·················@nyc.rr.com>, Kenny Tilton wrote:
>
>
> Marc Spitzer wrote:
>>
>> In article <·················@nyc.rr.com>, Kenny Tilton wrote:
>> >
>> >
>> > Drew McDermott wrote:
>> >>
>> >> A combination of the two would be dynamite. I produced a strongly typed
>> >> dialect of Lisp a few years ago, called Nisp, that has quite a few...
>> >
>> > Wow, you are the perfect sounding board, a True Lisper who loves strong
>> > typing (of variables, should I qualify?)
>> >
>> > Many Lispers see untyped variables as not just "not a problem" but
>> > furthermore as "an advantage", generally in its facilitation of RAD. But
>> > your position is clear insofar as you actually cooked up Nisp.
>> >
>> > At the risk of kicking off a firestorm, I'd love to hear why a dedicated
>> > Lisper loves strong typing so well.
>> >
>>
>> Are you talking about static typing?
>
> The Gotcha Squad strikes! Look guys, the OP said: "I produced a strongly
> typed dialect of Lisp a few years ago" and I knew what he meant, why not
> make the same effort?
wait a second, common lisp has strong typing, but it is dynamic not
static. Even with my limited knowledge on the subject I can tell the
difference between the two types. One short answer is that one
happens at run time and another happens at compile time. There is a
large difference between them. But both dynamic and static typing can
be strong or weak depending on how the language in question was
designed.
The I figured it out(guessed) why can't you make the same effort is a
silly argument. If you wish to have a discussion about something the
obvious first step is to clearly state the topics in a well defined
manner. The reason I asked for clarification was I was not sure about
what was being discussed, so I could (if possible) contribute in a
reasonable manner. I am not the "gotcha squad" and do not like the
implication.
>
> Because I might not know the difference? In my reply I mention "strong
> typing ... of variables" and "untyped variables"... only the third ref
> lazily mentions only "strong typing"... hello?
>
> Btw, Lisp is not statically typed? What about "3"?
it is a constant not a variable, they are different things entirely.
Any competent or not so competent(me for example) programmer should have
had that drummed into there skulls at college, if they believe it or
not they should still know the rules.
for example:
(setf bob "3" )
"3"
* (type-of bob)
(SIMPLE-BASE-STRING 1)
* (setf bob 3)
3
* (type-of bob)
FIXNUM
see strong but not static typing
marc
>
>:)
>
> --
>
> kenny tilton
> clinisys, inc
> ---------------------------------------------------------------
> "Well, I've wrestled with reality for thirty-five years, Doctor,
> and I'm happy to state I finally won out over it."
> Elwood P. Dowd
>>>>> "Marc" == Marc Spitzer <····@oscar.eng.cv.net> writes:
Marc> wait a second, common lisp has strong typing, but it is
Marc> dynamic not static.
OK, maybe I'm just stupid, but what the heck are the differences among
static, dynamic, strong, and weak typing? Everyone seems to be using
terminology interchangeably and I've lost track of what's what.
Help!?
--
Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!
I'm proud of my Northern Tibetian heritage! (http://www.subgenius.com)
"Matthew X. Economou" <···············@irtnog.org> writes:
> OK, maybe I'm just stupid, but what the heck are the differences among
> static, dynamic, strong, and weak typing? Everyone seems to be using
> terminology interchangeably and I've lost track of what's what.
>
> Help!?
Here's a good url that (I think) explains how academics [1]
use these terms:
http://www-ppg.dcs.st-and.ac.uk/Research/TypeSystems/
I hope this helps you.
[1] not pejorative- IME Usenauts rarely agree on what
"strong" and "weak" actually represent. Nevertheless,
the author of that url seems to spell it out pretty
clearly.
--
Joe Schaefer
>>>>> "Joe" == Joe Schaefer <··········@sunstarsys.com> writes:
Joe> http://www-ppg.dcs.st-and.ac.uk/Research/TypeSystems/
Joe> I hope this helps you.
It does. Thanks for the explanations, everyone.
--
Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!
I'm proud of my Northern Tibetian heritage! (http://www.subgenius.com)
In article <···············@eco-fs1.irtnog.org>,
"Matthew X. Economou" <···············@irtnog.org> wrote:
> >>>>> "Marc" == Marc Spitzer <····@oscar.eng.cv.net> writes:
>
> Marc> wait a second, common lisp has strong typing, but it is
> Marc> dynamic not static.
>
> OK, maybe I'm just stupid, but what the heck are the differences among
> static, dynamic, strong, and weak typing? Everyone seems to be using
> terminology interchangeably and I've lost track of what's what.
static = any errors will always be found at compile time.
dynamic = you don't find errors until you run it -- and even then, only
when you actually run the code that is in error.
strong = mixing up types is an error e.g. "foobar" + 2
weak = there are no types, or you silently get the bitpattern used as
the type you actually wanted (which probably doesn't give you the answer
you wanted).
The Lisp family is dynamically strongly typed.
The ML family is statically strongly typed.
The C family is weakly statically typed. (except Java, which is strongly
typed)
Some people would say that Perl is weakly dynamically typed, but I think
that's not right. It's more like a Lisp that happens to have a lot more
implicit conversions, such as already exist between integers, bignums,
floats, ratios etc.
Does that help?
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@eco-fs1.irtnog.org>,
> "Matthew X. Economou" <···············@irtnog.org> wrote:
>
> > >>>>> "Marc" == Marc Spitzer <····@oscar.eng.cv.net> writes:
> >
> > Marc> wait a second, common lisp has strong typing, but it is
> > Marc> dynamic not static.
> >
> > OK, maybe I'm just stupid, but what the heck are the differences among
> > static, dynamic, strong, and weak typing? Everyone seems to be using
> > terminology interchangeably and I've lost track of what's what.
>
> static = any errors will always be found at compile time.
False. C is statically typed, but it does not have this property.
Statically typed rather means that there is a static type system that
gives types to variables and expressions rather than to values.
What you refered to is usually called "safe". Formally, it is
captured by two theorems that people like to prove for the way their
static type systems interact with dynamic semantics: progress (any
statically well-typed expression is either a value or the dynamic
semantics allows for at least one more step to be taken), and "subject
reduction" (steps of the dynamic semantics always take terms to other
terms of equal type). Taken together the two mean that any program
that is (statically) well-typed to begin with will either continue to
run forever or it will arrive at a final value (result). Execution
will never encounter an ill-typed program, and if there is a final
value, then its type will be that of the original program.
--
-Matthias
Bruce Hoult <·····@hoult.org> writes:
> weak = there are no types, or you silently get the bitpattern used as
> the type you actually wanted (which probably doesn't give you the answer
> you wanted).
> ...
> Some people would say that Perl is weakly dynamically typed, but I think
> that's not right. It's more like a Lisp that happens to have a lot more
> implicit conversions, such as already exist between integers, bignums,
> floats, ratios etc.
Well, that's accurate, and it fits your definition of "weak". Look:
······@detached:~/pkgs/dl/fhack$ perl -wle 'use strict; print [] * 3'
405154548
In article <··············@panacea.canonical.org>,
Kragen Sitaker <······@pobox.com> wrote:
> Bruce Hoult <·····@hoult.org> writes:
> > weak = there are no types, or you silently get the bitpattern used as
> > the type you actually wanted (which probably doesn't give you the answer
> > you wanted).
> > ...
> > Some people would say that Perl is weakly dynamically typed, but I think
> > that's not right. It's more like a Lisp that happens to have a lot more
> > implicit conversions, such as already exist between integers, bignums,
> > floats, ratios etc.
>
> Well, that's accurate, and it fits your definition of "weak". Look:
> ······@detached:~/pkgs/dl/fhack$ perl -wle 'use strict; print [] * 3'
> 405154548
Ick, that is nasty. And I hadn't thought of that sort of thing.
Btw, I get 405645984 on my x86 Linux, 808167228 on MIPS Linux, and 76848
on OS X.
That's weakly-typed, for sure.
-- Bruce
····@oscar.eng.cv.net (Marc Spitzer) wrote in message news:<····················@oscar.eng.cv.net>...
>
> Are you talking about static typing? I have had lots of experience
> with CMUCL's strong typing, reciently. It is always telling me I
> cannot change this to that. I then figue out what I did wrong.
>
> Now static typing is completely different. You decide what all your
> type's(data structures) look like as the first step in program design,
> then if you need to change them half way through lots of stuff needs
> to be fixed. If you have not solved this problem at least twice befor
> you will probably make some mistakes in your types.
Static and Dynamic typing is not an either/or choice.
In the end they produce a continuum - at one end there are no freedom
for values to be inappropriate. At the other, all values have the
freedom to be inappropriate.
In CL you have the ability to determine how much type freedom you want
to permit, and a reasonably expressive type system (although it could
be a lot better with parametric class types to complement the
parametric builtins, for example).
This being the case, you can write CL programs where there is no
freedom for values to be incorrect at run-time - ie static systems,
but you aren't required to do so.
If we are to think clearly rather than ideologically, you can see that
type specification is just another way to express information about
the program, and should be used expressively, not generally for
optimisation purposes (with the usual caveats about profiler lead
optimisation for delivery, etc).
That is, I should say (declare (type (integer 0 1000) foo)) when I
want to _express_ that foo is a value beteen 0 and 1000 at all times -
I've established an invariant - and human beings (as well as
compilers) can read this and get information this way.
Used well, type declarations improve the expressivity of our programs,
used poorly they can form a straightjacket.
Personally, I suspect that the loathing and twitching that many CL
people exhibit when exposed to type declarations is due to a number of
appallingly bad CL compilers, for which there is no excuse in this day
and age.
Regards,
Brian.
On Sun, 02 Jun 2002 05:23:15 -0300, Brian Spilsbury wrote:
> ····@oscar.eng.cv.net (Marc Spitzer) wrote in message
> news:<····················@oscar.eng.cv.net>...
>
> Personally, I suspect that the loathing and twitching that many CL
> people exhibit when exposed to type declarations is due to a number of
> appallingly bad CL compilers, for which there is no excuse in this day
> and age.
>
> Regards,
>
> Brian.
Brian-
Can you name a few? In your Humble Opinion? (Ok, if it's going to start
a flame war...)
The reason I'm asking is that I like to see what are the different opinions
of exeperienced lispers regarding the implementations that are out there
today. I have no way of judging those at the moment.
Thank you
Henry
_________________________________________________________________
Micro$oft-Free Human 100% Debian GNU/Linux
KMFMS "Bring the genome to the people!
···········@debian-rs.org
www.debian.org - www.debian-br.cipsga.org.br - www.debian-rs.org
synthespian <···········@debian-rs.org> wrote in message news:<···································@debian-rs.org>...
> On Sun, 02 Jun 2002 05:23:15 -0300, Brian Spilsbury wrote:
>
> > ····@oscar.eng.cv.net (Marc Spitzer) wrote in message
> > news:<····················@oscar.eng.cv.net>...
> >
> > Personally, I suspect that the loathing and twitching that many CL
> > people exhibit when exposed to type declarations is due to a number of
> > appallingly bad CL compilers, for which there is no excuse in this day
> > and age.
> >
> > Regards,
> >
> > Brian.
>
> Brian-
>
> Can you name a few? In your Humble Opinion? (Ok, if it's going to start
> a flame war...)
> The reason I'm asking is that I like to see what are the different opinions
> of exeperienced lispers regarding the implementations that are out there
> today. I have no way of judging those at the moment.
Actually, I shouldn't have said appallingly bad compilers :)
A touch of hyperbole there - I meant poor in this specific context,
they may be quite wonderful otherwise.
Hmm, as for which compilers which are still in use which blindly trust
type declarations at normal safety levels...
ACL trusts declarations otherwise ignoring them.
Lispworks likewise turns off type-checking with a declaration present.
I suspect that it is the norm, rather than the exception to do so, but
I don't think that it is justified in modern times.
Regards,
Brian.
Kenny Tilton wrote:
>
> Drew McDermott wrote:
>
>>A combination of the two would be dynamite. I produced a strongly typed
>> dialect of Lisp a few years ago, called Nisp, that has quite a few...
>
> At the risk of kicking off a firestorm, I'd love to hear why a dedicated
> Lisper loves strong typing so well.
>
I used the word "strongly" in a woolly way; as others have made clear, I
should have said "statically."
Lisp is already statically typed, in the sense that one can declare
variables to be of various types, but the syntax for doing so is
cumbersome, and what the compiler actually does with the declarations is
a mystery.
What I want is to be able to write
(def-fun fact - Integer (n - Integer)
(cond ((= n 0) 1)
(t (* n (fact (- n 1))))))
and have the system realize that
(mapcar #'fact '(1 2 3))
is a list of Integers (of type (Lst Integer)). I also want the system
to catch type errors at compile time, although complete compile-time
type safety is too much to ask (and not especially interesting, in my
opinion).
[me]
> reconciling polymorphic types and inductive data types with
> Lisp programming style is surprisingly difficult.
[Kenny Tilton]
Do the difficulties feel like a "Message from God"(tm)? as in, there is
some a priori reason why the two cannot co-exist? I ask because whenever
I have a lot of trouble implementing some great idea I take is as a Bad
Sign.
My whole life sometimes seems like a Message from God....
However, there are two main problems, both connected with type
inference. One doesn't want to annotate every expression, or even every
variable and procedure, with its type, so the system should try to infer
types when possible. The standard way to do this is the Hindley-Milner
algorithm, where unspecified types are made into variables, and then
unification is used to find, for each type variable, a binding of that
variable that is consistent with all the uses of the thing it is the
type of.
The two main problems (wait, I just thought of a third):
1 getting &rest to work correctly,
2 dealing with subtypes
3 and assigning a type to a recursive function.
I've solved 1 and 2. It's 3 that's tricky. It's not hard in principle
(where "in principle" = "in ML," as usual), but it's often the case that
the calls to the function from within its own body are not sufficient to
constrain its type completely, especially in the presence of subtyping.
To paraphrase Fermat, I think I know how to solve 3, but I haven't been
able to find the time to work on it.
-- Drew McDermott
Drew McDermott <··············@yale.edu> writes:
> The two main problems (wait, I just thought of a third):
>
> 1 getting &rest to work correctly,
> 2 dealing with subtypes
> 3 and assigning a type to a recursive function.
>
> I've solved 1 and 2. It's 3 that's tricky. It's not hard in principle
> (where "in principle" = "in ML," as usual), but it's often the case that
> the calls to the function from within its own body are not sufficient to
> constrain its type completely, especially in the presence of subtyping.
>
> To paraphrase Fermat, I think I know how to solve 3, but I haven't been
> able to find the time to work on it.
I've tried to understand the approach in Soft Scheme to your third
problem (http://citeseer.nj.nec.com/8870.html), but I get seriously
confused by their type system. They reference a "Preliminary report on
a practical type inference system for Common Lisp" by Beer but I
haven't found anything more on that.
--
Bored, now.
Lieven Marchand <···@wyrd.be>
Drew McDermott wrote:
>
> reconciling polymorphic types and inductive data types with
> Lisp programming style is surprisingly difficult.
Do the difficulties feel like a "Message from God"(tm)? as in, there is
some a priori reason why the two cannot co-exist? I ask because whenever
I have a lot of trouble implementing some great idea I take is as a Bad
Sign.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd