Newbie questions about Pliant

Newbie questions about Pliant

Error handling

Examples of error handling
Message posted by grings on 2005/11/11 11:27:22
I need some examples of the error handling mechanism:
safe
  body
[success
  body2]
[failure
  body3]

Message posted by hubert.tonneau on 2005/11/11 11:36:40
There is a typo mistake in the documentation. It should be.

safe
  body
success
  body2
failure
  body3

body is executed, then when it ends, if there is no error pending, then
body2 is executed, else body3 is executed.

Here is an example (just uncomment the 'error' instruction to test the
other case):

function test
  safe
    console "Hello" eol
    # error "some trouble"
  success
    console "done." eol
  failure
    console "failed." eol

test

Message posted by grings on 2005/11/11 11:50:56
I want to capture exceptions such like:

function test
  safe
    var Array:Int a
    a:0:=0 #Exception here
  success
    console "done." eol
  failure
    console "failed." eol
test

Message posted by hubert.tonneau on 2005/11/11 13:19:03
Forget it. You can't.

An exception mechanism can only catch high level programming exceptions.

So, the question is: has 'Array' class been implemented high level.
The answer is no: it has been implemented low level (no boundaries check).

So, the problem is not really with the exception mechanism, but the fact that
you would like to use a 'SafeArray' data type that implements high level
arrays with boundaries checks.

This is a general issue shared by all programming languages.
As an exemple, C implements arrays as low level,
and Java implement them as high level.
Which is the best ?
None.
One is faster, the other makes programming a bit easier in some situations.

What is nice about Pliant is that it's flexible enough so that both
implementations are possible. The one defined as 'Array' and implemented in
/pliant/language/type/set/array.pli module is low level,
and anybody can decide to provide a catcheshigh level one.
The key issue is that in Pliant, there are no first class citizens (language
built in data types) on one hand, and second class ones (libraries implemented)
just like with most other languages (including C and Java), so you are free to
select what best meets your needs.
Message posted by maybe Boris Reitman on 2005/11/11 13:54:21
A question about array: there seems to be no 'each' support for a fixed array,
and also, for dynamic array, under 'each' there is no 'sort' support.

Why aren't fixed array and dynamic array unified to give consistent interface ? 
What about the sort support for array.

Thanks,
Boris
Message posted by hubert.tonneau on 2005/11/11 14:15:59
> A question about array: there seems to be no 'each' support for a fixed array,
> and also, for dynamic array, under 'each' there is no 'sort' support.

Generic 'each' is implemented in /pliant/language/type/set/each.pli
It relies on the availability of methods first, next, last and previous.

I have implemented these in 'Array' in module /pliant/language/type/set/array.pli
but not for fixed arrays implemented in module /pliant/language/type/set/fixedarray.pli

Nothing prevents to extend fixed array implementation.
Also i tend to believe that fixed array is very very low level, so rarely used,
so an extended API does not worth it.
Also this argument has no more value than beeing my personal taste.

> Why aren't fixed array and dynamic array unified to give consistent interface ? 
> What about the sort support for array.

'sort' is implemented for database 'Set' types in /pliant/appli/database/pointer.pli
(moved in /pliant/storage/database/pointer.pli in release 94),
so nothing prevents adapt the code to the generic version implemented in
/pliant/language/type/set/each.pli

Also, once again, the decision came only from my personal taste: when you scan
a database table, ordering and filtering is very frequent. On the other hand,
with an 'Array' you rarely want something else than ascending or descending
indexes, so I found the effort worseless.
Please keep in mind that stability is very high in my goals about Pliant,
so fullfeatured is not so high if it implies implementing features that I never
use, so don't get seriously tested.
If at some point Pliant get's a large user base, then things might change
because it means more testers.

Also I have a personal aversion against filling an as huge as possible features
set as a way to give value to the project, because I've seen so many reviews
on the web that reduce comparing two systems through a features set comparison,
and I find stupid since so far from reality.
My point of view is that the value of a system can only be seriously
evaluated from the negative point of view: when you put it at work, where do
you get troubles, because of lack of reliability, scalability, or impossibility
(because just impossible or too complex) to implement the more specific
extensions you need.

So, I'm not proud about the state of the documentation, even if there is no
shame about it because we have taken good options so that it will not stay
that bad forever, but I'm ok with the fact that some features are missing
that look bad when you just list the features set, as far as nobody brings
me real life sample that convience me that these features are truely usefull
in the real world.
Message posted by marcus on 2005/11/11 16:32:24
> There is a typo mistake in the documentation. It should be.

I'll fix that typo, as well as review the documentation later today.

M.
Message posted by marcus on 2005/11/11 20:10:04
Done.